From nobody Mon Jun 1 06:14:07 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8764A3A103E; Mon, 1 Jun 2020 06:14:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk CC: Liang Xia , kaduk@mit.edu, frank.xialiang@huawei.com, Valery Smyslov , dots-chairs@ietf.org, draft-ietf-dots-signal-filter-control@ietf.org, dots@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159101724453.21329.14437518255910895322@ietfa.amsl.com> Date: Mon, 01 Jun 2020 06:14:04 -0700 Archived-At: Subject: [Dots] Last Call: (Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel) to Proposed Standard X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 13:14:05 -0000 The IESG has received a request from the DDoS Open Threat Signaling WG (dots) to consider the following document: - 'Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an extension to the DOTS signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de- activate existing filtering rules during a DDoS attack. The characterization of these filtering rules is supposed to be conveyed by a DOTS client during an idle time by means of the DOTS data channel protocol. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Controlling Filtering Rules Using Distributed Denial- of-Service Open Threat Signaling (DOTS) Signal Channel"; o reference: RFC XXXX o [RFCXXXX] Please update the "revision" date of the YANG module. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jun 5 01:21:50 2020 Return-Path: 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 3038F3A13CF; Fri, 5 Jun 2020 01:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net 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 EjZuRq0gZ1vi; Fri, 5 Jun 2020 01:21:47 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 D3FDF3A13CE; Fri, 5 Jun 2020 01:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=G2qRLy8P5huBnkcO7kd7SOeTIZEEvAWMZ6IbDlbvW0U=; b=NmG37znsX3e8A/T//BQhlRGxJ8 O/H0Dt51j72YgpMD4pCsqV9aYpvWOPeOSUKubvMQbOyw88SDGaf8X09reEhrRzGTLoKGsTlk2PjeT MoIqmAQVNCoxuXVBmi7o0HRrZ36BOQEgPVug2lZuXhnJEy2ofW9udKR0G9vs5Yr2TqdA9LDuzmwFr 0YBjjulARNOIt/LZyhp/M0gzrtfjL3Ma+iaA/MB1YzH4hwCHXVb/mD0b5bpZwcvsfKmGTL1YpiVVu wlGZDvtKq1ye4W/4tKOvGlc9oPItRqZsmCDYnGaNRNkpRejidoIzNQkU5GLTBccIOxO6w1G3mwMw2 ZJBPMsdQ==; Received: from [82.138.51.4] (port=52423 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jh7bh-0004Dy-TT; Fri, 05 Jun 2020 04:21:42 -0400 From: "Valery Smyslov" To: Cc: , Date: Fri, 5 Jun 2020 11:21:35 +0300 Message-ID: <000901d63b12$56253f20$026fbd60$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdY7EOkTFt5JSs14SwuIcgvyvs0dYg== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [Dots] DOTS WG Virtual Interim Meeting Poll 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 08:21:49 -0000 Hi, since quite a lot of progress was recently done with the remaining DOTS documents, Frank and I (with Ben's approval) decided to organize a virtual interim meeting at the end of June. We've created a doodle poll for the most appropriate date and time of the meeting. We think that one-hour meeting is enough to discuss the remaining documents. The suggested dates are June 22, 23, 24, 25 and 25. We've included two possible time slots for each day that makes participants from both USA and Japan (two most distinct points) be able to participate without extreme inconvenience, but feel free to suggest other time slots. https://doodle.com/poll/kp6ymp875ztcsrq6 Please, participate in the poll and vote for the most appropriate date(s) for you. The poll will be active till June 11. Regards, Frank & Valery. From nobody Sat Jun 6 02:27:15 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EE23A0FFC; Sat, 6 Jun 2020 02:27:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: draft-ietf-dots-signal-filter-control.all@ietf.org, last-call@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159143563395.23234.11119777689885195262@ietfa.amsl.com> Reply-To: Christer Holmberg Date: Sat, 06 Jun 2020 02:27:14 -0700 Archived-At: Subject: [Dots] Genart last call review of draft-ietf-dots-signal-filter-control-04 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 09:27:14 -0000 Reviewer: Christer Holmberg Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dots-signal-filter-control-04 Reviewer: Christer Holmberg Review Date: 2020-06-06 IETF LC End Date: 2020-06-15 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and pretty much ready for publication. I do have a couple of minor editorial comments that I'd like the authors to address. Major issues: None Minor issues: None Nits/editorial comments: Q1: Please expand DOTS on first occurence. --- Q2: The Security Considerations say: "This specification does not allow to create new filtering rules, which is the responsibility of the DOTS data channel." Unless I missed it, I think it would be useful to state this also earlier in the document, e.g., in the Introduction. --- Q3: The Security Consideration say: "The security considerations discussed in [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need to be taken into account." I think it is obvious that those security considerations need to be taken into account. I would suggest to re-phrase, and say something like: "The generic security considerations for DOTS signal channels are defined in [I-D.ietf-dots-signal-channel]. The generic security considerations for DOTS data channels are defined in [I-D.ietf-dots-data-channel]. This Section defines the security considerations that are specific to the DOTS extension defined in this document." From nobody Sun Jun 7 22:24:10 2020 Return-Path: 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 44CF73A07D4; Sun, 7 Jun 2020 22:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 Ns-UeYt1Qk5U; Sun, 7 Jun 2020 22:24:07 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13533A07C7; Sun, 7 Jun 2020 22:24:06 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 49gM9w5d2Xz7tfM; Mon, 8 Jun 2020 07:24:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1591593844; bh=qNg6se/eE3ro7RV2CAU96XlMdSyM3llHYoON1UWzSes=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=toPgYKPJzKU4lbpD1a5ngWuTaE5EgkzVHk3AFTq3KDoxk4oDBJRef/uJKIrTZC7CE GiioULhljHPOBqEg2t1nDI0qewHAvDK0G+P6k0yUFEc4xzUMrkZojdM9aLTv6DBk/j 0lfVixwR0gv4zwfl6EIQ6hMhU3rpXQVWHnp0h3lOzNRnEPr57OjMeStFvAipuLmq5G xo32gYvDcOLdSJ5pu51HHpRGFMnvkdKgJ4Z8z5phgrrBEQk1mVNuFC5K9B/TsqUbyt hAVDltwWby0t4aZ6usFt6C+DTURxgEzNROYw0XMiMNBaD5smFUkDuJi5/PreZ90hrD M8Phu18dIG1sg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 49gM9w4Nbvz3wb8; Mon, 8 Jun 2020 07:24:04 +0200 (CEST) From: To: Christer Holmberg , "gen-art@ietf.org" CC: "draft-ietf-dots-signal-filter-control.all@ietf.org" , "last-call@ietf.org" , "dots@ietf.org" Thread-Topic: Genart last call review of draft-ietf-dots-signal-filter-control-04 Thread-Index: AQHWO+SrEOgeBzAJe0askGmqmw9G2ajOL9gw Date: Mon, 8 Jun 2020 05:24:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314D96A7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159143563395.23234.11119777689885195262@ietfa.amsl.com> In-Reply-To: <159143563395.23234.11119777689885195262@ietfa.amsl.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Genart last call review of draft-ietf-dots-signal-filter-control-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 05:24:08 -0000 SGkgQ2hyaXN0ZXIsIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpPSyB3aXRoIGFs bCB5b3VyIHN1Z2dlc3Rpb25zLiANCg0KRldJVywgeW91IGNhbiB0cmFjayB0aGUgY2hhbmdlcyB0 byBhZGRyZXNzIHlvdXIgcmV2aWV3IGF0OiBodHRwczovL2dpdGh1Yi5jb20vYm91Y2FkYWlyL2Zp bHRlci1jb250cm9sL2Jsb2IvbWFzdGVyL0NocmlzdGVyJ3MlMjBSZXZpZXcucGRmIA0KDQpDaGVl cnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogQ2hyaXN0 ZXIgSG9sbWJlcmcgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4g RW52b3nDqcKgOiBzYW1lZGkgNiBqdWluIDIwMjAgMTE6MjcNCj4gw4DCoDogZ2VuLWFydEBpZXRm Lm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci1jb250cm9sLmFsbEBp ZXRmLm9yZzsgbGFzdC0NCj4gY2FsbEBpZXRmLm9yZzsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKg OiBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRl ci0NCj4gY29udHJvbC0wNA0KPiANCj4gUmV2aWV3ZXI6IENocmlzdGVyIEhvbG1iZXJnDQo+IFJl dmlldyByZXN1bHQ6IFJlYWR5IHdpdGggTml0cw0KPiANCj4gSSBhbSB0aGUgYXNzaWduZWQgR2Vu LUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYQ0KPiBSZXZpZXcg VGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2Vk DQo+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0DQo+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+ IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4gDQo+IDxodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+Lg0KPiANCj4gRG9jdW1l bnQ6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVyLWNvbnRyb2wtMDQNCj4gUmV2aWV3ZXI6 IENocmlzdGVyIEhvbG1iZXJnDQo+IFJldmlldyBEYXRlOiAyMDIwLTA2LTA2DQo+IElFVEYgTEMg RW5kIERhdGU6IDIwMjAtMDYtMTUNCj4gSUVTRyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVk IGZvciBhIHRlbGVjaGF0DQo+IA0KPiBTdW1tYXJ5OiBUaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0 dGVuLCBhbmQgcHJldHR5IG11Y2ggcmVhZHkgZm9yDQo+IHB1YmxpY2F0aW9uLiBJDQo+IGRvIGhh dmUgYSBjb3VwbGUgb2YgbWlub3IgZWRpdG9yaWFsIGNvbW1lbnRzIHRoYXQgSSdkIGxpa2UgdGhl IGF1dGhvcnMNCj4gdG8NCj4gYWRkcmVzcy4NCj4gDQo+IE1ham9yIGlzc3VlczogTm9uZQ0KPiAN Cj4gTWlub3IgaXNzdWVzOiBOb25lDQo+IA0KPiBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCj4g DQo+IFExOiAgUGxlYXNlIGV4cGFuZCBET1RTIG9uIGZpcnN0IG9jY3VyZW5jZS4NCj4gDQo+IC0t LQ0KPiANCj4gUTI6ICBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2F5Og0KPiANCj4gICAg IlRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBhbGxvdyB0byBjcmVhdGUgbmV3IGZpbHRlcmlu ZyBydWxlcywNCj4gICAgd2hpY2ggaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBET1RTIGRh dGEgY2hhbm5lbC4iDQo+IA0KPiBVbmxlc3MgSSBtaXNzZWQgaXQsIEkgdGhpbmsgaXQgd291bGQg YmUgdXNlZnVsIHRvIHN0YXRlIHRoaXMgYWxzbw0KPiBlYXJsaWVyIGluDQo+IHRoZSBkb2N1bWVu dCwgZS5nLiwgaW4gdGhlIEludHJvZHVjdGlvbi4NCj4gDQo+IC0tLQ0KPiANCj4gUTM6IFRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9uIHNheToNCj4gDQo+ICAgICJUaGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgZGlzY3Vzc2VkIGluDQo+ICAgIFtJLUQuaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVs XSBhbmQgW0ktRC5pZXRmLWRvdHMtZGF0YS1jaGFubmVsXQ0KPiBuZWVkDQo+ICAgIHRvIGJlIHRh a2VuIGludG8gYWNjb3VudC4iDQo+IA0KPiBJIHRoaW5rIGl0IGlzIG9idmlvdXMgdGhhdCB0aG9z ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBuZWVkIHRvIGJlDQo+IHRha2VuIGludG8NCj4gYWNj b3VudC4gSSB3b3VsZCBzdWdnZXN0IHRvIHJlLXBocmFzZSwgYW5kIHNheSBzb21ldGhpbmcgbGlr ZToNCj4gDQo+ICAgICJUaGUgZ2VuZXJpYyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgRE9U UyBzaWduYWwgY2hhbm5lbHMgYXJlDQo+ICAgIGRlZmluZWQgaW4gICBbSS1ELmlldGYtZG90cy1z aWduYWwtY2hhbm5lbF0uIFRoZSBnZW5lcmljIHNlY3VyaXR5DQo+ICAgIGNvbnNpZGVyYXRpb25z IGZvciBET1RTIGRhdGEgY2hhbm5lbHMgYXJlIGRlZmluZWQgaW4NCj4gICAgW0ktRC5pZXRmLWRv dHMtZGF0YS1jaGFubmVsXS4gVGhpcyBTZWN0aW9uIGRlZmluZXMgdGhlIHNlY3VyaXR5DQo+ICAg IGNvbnNpZGVyYXRpb25zIHRoYXQgYXJlIHNwZWNpZmljIHRvIHRoZSBET1RTIGV4dGVuc2lvbiBk ZWZpbmVkDQo+ICAgIGluIHRoaXMgZG9jdW1lbnQuIg0KPiANCj4gDQoNCg== From nobody Sun Jun 7 22:43:11 2020 Return-Path: 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 993E83A0840; Sun, 7 Jun 2020 22:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 WNioREYnFNdy; Sun, 7 Jun 2020 22:42:59 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60054.outbound.protection.outlook.com [40.107.6.54]) (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 880DA3A083E; Sun, 7 Jun 2020 22:42:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JknvFQZ2H9BH806htT424DZUg15CyL1S5wPyTOghrpMo9+DBNhK2LGz679XwCqNJBJrSYhnLhiPkSFlb8cPunjTYCnDy0aFh7ExC+fJOpQ5i3yrf3suYbOYBrMVqmbCEK1naOVzBhnKYXMwls3hAXFVLhqx5hHzlqlJ1V9W8uAA19NQAzKbDOKRnJBcYYrwuOEecRIc+lDiPhv/cSUMNOvtBJUA0wr80PAAcxVXSfTzOmmNdAzE3UUZ+c2XZG/AmAJPo74hhF157WPsSEuiXjZq67KAPXdlRq6fTyeR6GCMpQl/7edjNTO/YzRfErBpjtWzwPDJXef95RvQkLcH5gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ROqJufCosbIy3cpnKQ7D+RYMbBMhtl2D17aBoduuaEw=; b=htRQkkdMkMDeoxB7Az2kOhfLsdqNeJ1huIqL0HXVc0srCiJVUvOm/hn0UKnFAn8ToXyaPjpM0JUiw+s1paL39gwvt0vccADtODDK4msnkkmOM7evYoM7E47Qy+0C6me0vSFWCMNJ9Ezt70GWesEwmvCBgTpO2Jgtbftyz3D7qKWmhk/OEnUov8TOsrt64WN6abHlkPsD0xOjAhYDXhofqWHEuOFOrT0SWn8tYjoSJf0aM080DPvihpYkIrKw6QfLiTfWmOntWcyGOSohQMoc1vNOO6OZoDUPfhgOemScQ0tq1MX4yBs71ZSZc+RFkEfk1TgEkYgzYgFASCz4s1OM+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ROqJufCosbIy3cpnKQ7D+RYMbBMhtl2D17aBoduuaEw=; b=fmPZRCGTTOMlLUIZ6N2QVMsaw9JYSj4KTjQJ6IuaXdUosT6fcFhNXc8R/ldXx/rhMl+/qQIAFhIvUo/wkTKMUhBusT51atZO2Yqs9B3mu+vzGBod09MRDR/X1Ub/3wIi1DQneKLdY01AkHvd/MBpYVp2cPWJcMw+KA3RZq4Owf0= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM5PR0701MB2449.eurprd07.prod.outlook.com (2603:10a6:203:e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.15; Mon, 8 Jun 2020 05:42:57 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3088.016; Mon, 8 Jun 2020 05:42:57 +0000 From: Christer Holmberg To: "mohamed.boucadair@orange.com" , "gen-art@ietf.org" CC: "draft-ietf-dots-signal-filter-control.all@ietf.org" , "last-call@ietf.org" , "dots@ietf.org" Thread-Topic: Genart last call review of draft-ietf-dots-signal-filter-control-04 Thread-Index: AQHWPVULIBO6JjtPiEKwjx7QdZRia6jONIlw Date: Mon, 8 Jun 2020 05:42:56 +0000 Message-ID: References: <159143563395.23234.11119777689885195262@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330314D96A7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314D96A7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9a1ff00b-5c73-4eb0-2f71-08d80b6ecc11 x-ms-traffictypediagnostic: AM5PR0701MB2449: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 042857DBB5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LePI8RuyuTPE4rhB1AjgoZvP00NvPugAwoL4hdi9HojKJeI3qjgEgb2l39R0gIPYy6PJuxk6TOxcYTPCexJ6JFS8d/Hvi9KRdehxMl6MzsCIIlxvaXI7rK9DYFBOMmrpPhIwjwyaYeckAcwLYluGJSOcepP7Qo8JRscrBShNWV3+3TXPmLwGY3p0vxhgl42TOhfo2iFgC3sqIHGfmFmQ+Bkks0WA+s8h/M8JyIe2zrCEhXVb5QTnB0vWy8avoXk73qDd0YzmraLSp1BTI6cdmIYfFq035F78BTL7jSfsJiH6nlOxhQyU/4tm8FAN0WiQpXwVDK/8pAqdhzMq3n2GsW+dKmUPpXccQyiuQBWdNE/2qzjCJYxW8lOAzcM5i+iWjk/JHtnLBpKAtRKnOHrS0g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(136003)(366004)(39860400002)(33656002)(7696005)(86362001)(9686003)(44832011)(83380400001)(110136005)(4326008)(6506007)(8936002)(186003)(26005)(8676002)(54906003)(71200400001)(2906002)(52536014)(66446008)(316002)(66476007)(66556008)(76116006)(66946007)(5660300002)(966005)(55016002)(64756008)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Bal+7n3JH+dxh7DuijhhY1nCFxQYR/jYOs8nuAPhhyD8x2evZaQHZfB9BakkPcxZaBOLjcuBBBWN15JCGyTov1r6b0QVk0E4Wdpkuvr+icQe7aDdsMsNUC7g/7FZmszqJzlkPYcV3Cq/z0CCclhpUe9ZF3O0tyTu9esuWk1AMSsCVxCvd7D47YPFHBGfzQSAOLDDSj10w681wNeQQZbKB2mQuAtnxMH63IAC26+k6kCyQ7HmwKBqUB7+VfydV4WfWMpTuRFxYioh0u9SQ1+p31OBVjYttsoWq/YpuHzehc0g03dx5wb8IcslkJEDB+Kggi9Y5l2aXwWgV6vM35vaCy235fKWljWrYmPEu9AAUxxVg+f+FkswTuqGJxAVuA1RF5DjPns040rQIKIS9hR+2VzRytnFPYFMOOyUzm/6DoVWi2iXi9kz25cQN1VF2YmMbT0QVjIK1im2V4J9vESyLzl5v4RM4dRDk0etTjnNe+ncawhniH6JUrtbhRuiWmbE x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a1ff00b-5c73-4eb0-2f71-08d80b6ecc11 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 05:42:57.0493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bNSA7/rN0h7/VZx/sl28DXttHn0nlv+HBUD8V+6P4br2iRkrfz2hZJCoNlzkrhF8yfHAKH8ObNWrEDhFBgdSMh1YuDd3YLt1U9gitmaxEjc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2449 Archived-At: Subject: Re: [Dots] Genart last call review of draft-ietf-dots-signal-filter-control-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 05:43:02 -0000 SGksDQoNCj5UaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KPg0KPk9LIHdpdGggYWxsIHlvdXIg c3VnZ2VzdGlvbnMuIA0KDQpUaGFuayBZb3UhIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQpGV0lXLCB5b3UgY2FuIHRyYWNrIHRoZSBjaGFuZ2VzIHRvIGFkZHJlc3MgeW91ciByZXZp ZXcgYXQ6IGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9ZGIwZjYwNDEtODVh ZmEzZTgtZGIwZjIwZGEtODY5NTllNDcyMjQzLTVmYWViODJiM2M5MGJmNTEmcT0xJmU9ZjQzYzUw YjctYWMwYi00ZWJhLWJjNGItNTVjMGU3ZjhhMmI5JnU9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29t JTJGYm91Y2FkYWlyJTJGZmlsdGVyLWNvbnRyb2wlMkZibG9iJTJGbWFzdGVyJTJGQ2hyaXN0ZXIn cyUyMFJldmlldy5wZGYgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiBEZcKgOiBDaHJpc3RlciBIb2xtYmVyZyB2aWEgRGF0YXRyYWNrZXIgW21haWx0 bzpub3JlcGx5QGlldGYub3JnXSANCj4gRW52b3nDqcKgOiBzYW1lZGkgNiBqdWluIDIwMjAgMTE6 Mjcgw4DCoDogZ2VuLWFydEBpZXRmLm9yZyBDY8KgOiANCj4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25h bC1maWx0ZXItY29udHJvbC5hbGxAaWV0Zi5vcmc7IGxhc3QtIA0KPiBjYWxsQGlldGYub3JnOyBk b3RzQGlldGYub3JnIE9iamV0wqA6IEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIA0KPiBkcmFm dC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci0NCj4gY29udHJvbC0wNA0KPiANCj4gUmV2aWV3ZXI6 IENocmlzdGVyIEhvbG1iZXJnDQo+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggTml0cw0KPiAN Cj4gSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhl IEdlbmVyYWwgQXJlYSANCj4gUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSANCj4gdGhlIElFU0cgZm9yIHRoZSBJRVRGIENo YWlyLiAgUGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSANCj4gYW55IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ug c2VlIHRoZSBGQVEgYXQNCj4gDQo+IDxodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lr aS9HZW5BcnRmYXE+Lg0KPiANCj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmls dGVyLWNvbnRyb2wtMDQNCj4gUmV2aWV3ZXI6IENocmlzdGVyIEhvbG1iZXJnDQo+IFJldmlldyBE YXRlOiAyMDIwLTA2LTA2DQo+IElFVEYgTEMgRW5kIERhdGU6IDIwMjAtMDYtMTUNCj4gSUVTRyBU ZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRlbGVjaGF0DQo+IA0KPiBTdW1tYXJ5 OiBUaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuLCBhbmQgcHJldHR5IG11Y2ggcmVhZHkgZm9y IA0KPiBwdWJsaWNhdGlvbi4gSSBkbyBoYXZlIGEgY291cGxlIG9mIG1pbm9yIGVkaXRvcmlhbCBj b21tZW50cyB0aGF0IEknZCANCj4gbGlrZSB0aGUgYXV0aG9ycyB0byBhZGRyZXNzLg0KPiANCj4g TWFqb3IgaXNzdWVzOiBOb25lDQo+IA0KPiBNaW5vciBpc3N1ZXM6IE5vbmUNCj4gDQo+IE5pdHMv ZWRpdG9yaWFsIGNvbW1lbnRzOg0KPiANCj4gUTE6ICBQbGVhc2UgZXhwYW5kIERPVFMgb24gZmly c3Qgb2NjdXJlbmNlLg0KPiANCj4gLS0tDQo+IA0KPiBRMjogIFRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzYXk6DQo+IA0KPiAgICAiVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGFsbG93 IHRvIGNyZWF0ZSBuZXcgZmlsdGVyaW5nIHJ1bGVzLA0KPiAgICB3aGljaCBpcyB0aGUgcmVzcG9u c2liaWxpdHkgb2YgdGhlIERPVFMgZGF0YSBjaGFubmVsLiINCj4gDQo+IFVubGVzcyBJIG1pc3Nl ZCBpdCwgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gc3RhdGUgdGhpcyBhbHNvIA0KPiBl YXJsaWVyIGluIHRoZSBkb2N1bWVudCwgZS5nLiwgaW4gdGhlIEludHJvZHVjdGlvbi4NCj4gDQo+ IC0tLQ0KPiANCj4gUTM6IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uIHNheToNCj4gDQo+ICAg ICJUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluDQo+ICAgIFtJLUQuaWV0 Zi1kb3RzLXNpZ25hbC1jaGFubmVsXSBhbmQgW0ktRC5pZXRmLWRvdHMtZGF0YS1jaGFubmVsXSAN Cj4gbmVlZA0KPiAgICB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQuIg0KPiANCj4gSSB0aGluayBp dCBpcyBvYnZpb3VzIHRoYXQgdGhvc2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgbmVlZCB0byBi ZSANCj4gdGFrZW4gaW50byBhY2NvdW50LiBJIHdvdWxkIHN1Z2dlc3QgdG8gcmUtcGhyYXNlLCBh bmQgc2F5IHNvbWV0aGluZyANCj4gbGlrZToNCj4gDQo+ICAgICJUaGUgZ2VuZXJpYyBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBmb3IgRE9UUyBzaWduYWwgY2hhbm5lbHMgYXJlDQo+ICAgIGRlZmlu ZWQgaW4gICBbSS1ELmlldGYtZG90cy1zaWduYWwtY2hhbm5lbF0uIFRoZSBnZW5lcmljIHNlY3Vy aXR5DQo+ICAgIGNvbnNpZGVyYXRpb25zIGZvciBET1RTIGRhdGEgY2hhbm5lbHMgYXJlIGRlZmlu ZWQgaW4NCj4gICAgW0ktRC5pZXRmLWRvdHMtZGF0YS1jaGFubmVsXS4gVGhpcyBTZWN0aW9uIGRl ZmluZXMgdGhlIHNlY3VyaXR5DQo+ICAgIGNvbnNpZGVyYXRpb25zIHRoYXQgYXJlIHNwZWNpZmlj IHRvIHRoZSBET1RTIGV4dGVuc2lvbiBkZWZpbmVkDQo+ICAgIGluIHRoaXMgZG9jdW1lbnQuIg0K PiANCj4gDQoNCg== From nobody Wed Jun 10 09:00:14 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F2E3A0B14; Wed, 10 Jun 2020 09:00:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Elwyn Davies via Datatracker To: Cc: dots@ietf.org, last-call@ietf.org, draft-ietf-dots-use-cases.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159180480429.20695.13967711651987137436@ietfa.amsl.com> Reply-To: Elwyn Davies Date: Wed, 10 Jun 2020 09:00:04 -0700 Archived-At: Subject: [Dots] Genart last call review of draft-ietf-dots-use-cases-23 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 16:00:10 -0000 Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dots-use-cases-23 Reviewer: Elwyn Davies Review Date: 2020-06-10 IETF LC End Date: 2020-06-11 IESG Telechat date: Not scheduled for a telechat Summary: Ready wih some minor nits. Major issues: None Minor issues: None Nits/editorial comments: s1, para 1: Just a thought: might be worth adding to the end of this para: "and increase the time for deployment in a situation where speed is often of the essence". s1, last para: Suggest adding in reference to DOTS requirements doc which is referred to in s2: OLD: This document provides sample use cases that provided input for the design of the DOTS protocols [RFC8782][RFC8783]. NEW This document provides sample use cases that motivated the requirements for the DOTS protocols [RFC8612] and provided input for the design of those protocols [RFC8782][RFC8783]. ENDS s2: For more logical ordering, move the definition of DDos Mitigation Service Provider after definition of DDoS Mitigation Service. s2, DDoS Mitigation Service: OLD: Service subscriptions usually involve Service Level Agreement (SLA) that have to be met. NEW: Each service subscription usually involves a Service Level Agreement (SLA) that has to be met. ENDS s3.1, para 1: The abbreviation ITP has already been defined so you shouldn't have a redefinition here. s3.1, para 7: s/thought different/though different/ s3.1, 2nd set of bullets, that are below Fig 1: This woud be more elegant using (a), (b), etc as the bullet labels. s3.1: Comment (not being familiar with the DOTS proposals): The text indicates that the ITP mitigation effort is an all or nothing buisness. Is this always the case or could the client request or the server provide a proportional response rather than an all or nothing response? s3.2, last sentence of 2nd para after Fig 2: s/These exact/The exact/ s3.3, para 2: s/various information/various sets of information/ s3.3, para after Figure 4: s/monitor various network traffic/monitor various aspects of the network traffic/. s3.3, 2nd para after Figure 4: s/it's/it is/ s3.3, last five paras: Calling out a web interface specifically is overly specific. Suggest adding 'for example'in at least one case or changing it to 'user interface'. s3.3, first para on page 11: OLD: to infer the DDoS Mitigation to elaborate and coordinate. NEW: to infer, elaborate and coordinate the appropriate DDoS Mitigation. ENDS s3.3, 3rd and subsequent paras on page 11: The orchestrator appears to change from one DOTS server to a plurality at this point. Please make it clear whether there is one or many. If only one, then s/The orchestrator DOTS servers returns this information back/The orchestrator DOTS server returns this information/ and s/servers/server/ subsequently. s3.3, last para s/like requesting/such as requesting/ s7: This is an informational document and, as such, cannot have normative references. Please combine all references into one refererences section. From nobody Wed Jun 10 09:20:19 2020 Return-Path: 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 9C4F73A0859; Wed, 10 Jun 2020 09:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 ZxVQGqPnJBvO; Wed, 10 Jun 2020 09:20:11 -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 A85473A09DD; Wed, 10 Jun 2020 09:20:10 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 49hsf06kDWz1yPf; Wed, 10 Jun 2020 18:20:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1591806008; bh=bKlkxYphncsIGyC40dV+OxqFMjOWunL5zaX/pv2Pf0Y=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=dd2CuoVO0J+nHiFmbDlButDbW7xPPW53hlFHag88jBXXcDM4FYIPmkRdxCXmt5AZy kVxGDMsP6szwxUs7ReYXuR8onByl5DFxBbL2xhMOM1qrXJy+Y+AzoiB9WNU9VOapgf 6xa3taZH3d2/+/Ih7o3sSH9kJxnhk3nQ5o+ZsY9ESvm5v1bY1TopVWo7fPzIRzW8b/ Xgyjr2Whcl78VsCvMnWPeQtvDULtXo0fZvspO8YTVQStPZW1JSpH+1l0nZOvm8Pylk 6h/Gcad6vxdx966WZOG/Jnxw33qcfCapBjR/QbfQWDUGh5oV5WCpm8MLk0JftMYwCS Lc3WvCjBng+Ng== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 49hsf05Nl4z8sc0; Wed, 10 Jun 2020 18:20:08 +0200 (CEST) From: To: Elwyn Davies , "gen-art@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-dots-use-cases.all@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] Genart last call review of draft-ietf-dots-use-cases-23 Thread-Index: AQHWP0B7B0JXoEQIeEui4Gt6hRmHFajSBQFQ Date: Wed, 10 Jun 2020 16:20:07 +0000 Message-ID: <19733_1591806008_5EE10838_19733_230_7_787AE7BB302AE849A7480A190F8B9330314DB94C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159180480429.20695.13967711651987137436@ietfa.amsl.com> In-Reply-To: <159180480429.20695.13967711651987137436@ietfa.amsl.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Genart last call review of draft-ietf-dots-use-cases-23 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 16:20:13 -0000 Dear Elwyn,=20 One quick comment about: > s7: This is an informational document and, as such, cannot have > normative > references. Please combine all references into one refererences > section. If we refer to the IESG statement available at: https://ietf.org/about/grou= ps/iesg/statements/normative-informative-references/, we can read the follo= wing: "Note 3: The normative/informative distinction is relevant in any document = that amounts to a technical specification, even if its intended status is E= xperimental or Informational." So, that's fine to have a normative ref section (if justified) for this doc= ument. That's said, I do personally think that at least [RFC8782][RFC8783] have to= be moved as Informative... but not for the reasons mentioned in the review= .=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Elwyn Davies > via Datatracker > Envoy=E9=A0: mercredi 10 juin 2020 18:00 > =C0=A0: gen-art@ietf.org > Cc=A0: last-call@ietf.org; draft-ietf-dots-use-cases.all@ietf.org; > dots@ietf.org > Objet=A0: [Dots] Genart last call review of draft-ietf-dots-use-cases-23 >=20 > Reviewer: Elwyn Davies > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-dots-use-cases-23 > Reviewer: Elwyn Davies > Review Date: 2020-06-10 > IETF LC End Date: 2020-06-11 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > Ready wih some minor nits. >=20 > Major issues: > None >=20 > Minor issues: > None >=20 > Nits/editorial comments: > s1, para 1: Just a thought: might be worth adding to the end of this > para: > "and increase the time for deployment in a situation where speed is > often of > the essence". >=20 > s1, last para: Suggest adding in reference to DOTS requirements doc > which is > referred to in s2: OLD: > This document provides sample use cases that provided input for the > design of the DOTS protocols [RFC8782][RFC8783]. > NEW > This document provides sample use cases that motivated the > requirements > for the DOTS protocols [RFC8612] and provided input for the design > of > those protocols [RFC8782][RFC8783]. > ENDS >=20 > s2: For more logical ordering, move the definition of DDos Mitigation > Service > Provider after definition of DDoS Mitigation Service. >=20 > s2, DDoS Mitigation Service: > OLD: > Service subscriptions usually > involve Service Level Agreement (SLA) that have to be met. > NEW: > Each service subscription usually > involves a Service Level Agreement (SLA) that has to be met. > ENDS >=20 > s3.1, para 1: The abbreviation ITP has already been defined so you > shouldn't > have a redefinition here. >=20 > s3.1, para 7: s/thought different/though different/ >=20 > s3.1, 2nd set of bullets, that are below Fig 1: This woud be more > elegant using > (a), (b), etc as the bullet labels. >=20 > s3.1: Comment (not being familiar with the DOTS proposals): The text > indicates > that the ITP mitigation effort is an all or nothing buisness. Is this > always > the case or could the client request or the server provide a > proportional > response rather than an all or nothing response? >=20 > s3.2, last sentence of 2nd para after Fig 2: s/These exact/The exact/ >=20 > s3.3, para 2: s/various information/various sets of information/ >=20 > s3.3, para after Figure 4: s/monitor various network traffic/monitor > various > aspects of the network traffic/. >=20 > s3.3, 2nd para after Figure 4: s/it's/it is/ >=20 > s3.3, last five paras: Calling out a web interface specifically is > overly > specific. Suggest adding 'for example'in at least one case or > changing it to > 'user interface'. >=20 > s3.3, first para on page 11: > OLD: > to infer the DDoS Mitigation to elaborate and coordinate. > NEW: > to infer, elaborate and coordinate the appropriate DDoS Mitigation. > ENDS >=20 > s3.3, 3rd and subsequent paras on page 11: The orchestrator appears to > change > from one DOTS server to a plurality at this point. Please make it > clear > whether there is one or many. If only one, then s/The orchestrator > DOTS > servers returns this information back/The orchestrator DOTS server > returns this > information/ and s/servers/server/ subsequently. >=20 > s3.3, last para s/like requesting/such as requesting/ >=20 > s7: This is an informational document and, as such, cannot have > normative > references. Please combine all references into one refererences > section. >=20 >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Thu Jun 11 02:01:48 2020 Return-Path: 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 497263A1776; Thu, 11 Jun 2020 02:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RO3l3U5cjFDL; Thu, 11 Jun 2020 02:01:45 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5043A1774; Thu, 11 Jun 2020 02:01:44 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 82so3096658lfh.2; Thu, 11 Jun 2020 02:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=uqEvbFmJwdQNE7yRuP1VZDBthly4rnEsewydwV4yjmQ=; b=jM9pEcdM7W1fhbEtcUkZTWzhAQSLL+iw0qa9S3u6lN7N+eieJVKNorkInynEiHmG83 CyWWrA2DAjREnUxrWPRG7niCuFPXkCEuBCR18nDvgq3hP1raAcVBIz3pGBUM4pLXauDf 0Nffqrlm60pHWGgK6AsTc/gd7HZ5G1SJtzux5+OszdTuZPx6+Eh/0HpCo7g8wb6CE2X0 w1CRDUSLt8D3oI8gGcxukWM9CPPgxAY0qQRP8tNpDg5D0Y0EoL9NvoNaA7hHnROOkNte 62sbJ66n/Y2JPHaN1e6ixbG9IevxN1m7SPRZqWPsldFxkCD7MnJqxArNkfMLUzOfGBN+ B69w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=uqEvbFmJwdQNE7yRuP1VZDBthly4rnEsewydwV4yjmQ=; b=Zglew6yKWK7rGjyR4mdiukzeSrIUNZWCPDM3s7EMC8fBcpNrveAvYbRkaXVaq4fsCJ tftwOgT7pbRbvBk9G+YfyDdqOLdKhdw1a2lJ3B4EBR+y2sWzrjy1qL/Eo6waEv1Pf3FZ K7kn6Er4ORFK/p5Mb4uca5Nnw7Rph53de+Q9fi2imam5FplxqomJnn5Glif76CbTFAtH VzXbawzDZ26CAiaLgAs2Qta3kMM6zY03Bc/jetSd/UGjcfcjNIHiEMoWcRDAjW/O7Hy5 ql79zaiCM67I9n06hiSv709OctI+CppRP5qmQxuPazY42Olesb5EQ//coHfgNKwbGlFS n0RA== X-Gm-Message-State: AOAM533Q7QW6lZeQBTPG8QdUYvgHLLjj+wYcclvr93pN/NzrRv2FZlLl TzmdnRf65Yw30qLQvpIIuJmk9d4S X-Google-Smtp-Source: ABdhPJwc0szYDXQKgPb+qpHP7UPwvKyPJKsGsizsVGPnZ7EJQiibrExcTz/PwjVzBdXb7jXil7b+Vg== X-Received: by 2002:a05:6512:3139:: with SMTP id p25mr3746646lfd.214.1591866102206; Thu, 11 Jun 2020 02:01:42 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q17sm631356lfa.28.2020.06.11.02.01.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 02:01:41 -0700 (PDT) From: "Valery Smyslov" To: Cc: , References: <000901d63b12$56253f20$026fbd60$@smyslov.net> In-Reply-To: <000901d63b12$56253f20$026fbd60$@smyslov.net> Date: Thu, 11 Jun 2020 12:01:33 +0300 Message-ID: <002c01d63fce$e7e86bb0$b7b94310$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDwF1oJXFe0YsSqTdFRoL4urEAvF6qfZIxg Content-Language: ru Archived-At: Subject: Re: [Dots] DOTS WG Virtual Interim Meeting Poll 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 09:01:46 -0000 Hi, according to the poll results, June the 25th 6:00 UTC and June the 26th 6:00 UTC are most appropriate for majority of participants. We'll proceed with the first of these dates: June the 25th 6:00 UTC Regards, Frank & Valery. > Hi, > > since quite a lot of progress was recently done with the remaining DOTS documents, > Frank and I (with Ben's approval) decided to organize a virtual interim meeting > at the end of June. > > We've created a doodle poll for the most appropriate date and time of the meeting. > We think that one-hour meeting is enough to discuss the remaining documents. > The suggested dates are June 22, 23, 24, 25 and 25. > We've included two possible time slots for each day that makes participants from both > USA and Japan (two most distinct points) be able to participate without > extreme inconvenience, but feel free to suggest other time slots. > > https://doodle.com/poll/kp6ymp875ztcsrq6 > > Please, participate in the poll and vote for the most appropriate date(s) for you. > The poll will be active till June 11. > > Regards, > Frank & Valery. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Jun 11 02:07:31 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CF73A0FAB; Thu, 11 Jun 2020 02:07:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dots@ietf.org, valery@smyslov.net, kaduk@mit.edu, dots-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159186645008.7268.4981595232702739295@ietfa.amsl.com> Date: Thu, 11 Jun 2020 02:07:30 -0700 Archived-At: Subject: [Dots] dots - Not having a session at IETF 108 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 09:07:30 -0000 Valery Smyslov, a chair of the dots working group, indicated that the dots working group does not plan to hold a session at IETF 108. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Jun 11 05:18:18 2020 Return-Path: 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 B3B093A07BA for ; Thu, 11 Jun 2020 05:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net 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 JxefDfe4CPBm for ; Thu, 11 Jun 2020 05:18:14 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 35B673A07AA for ; Thu, 11 Jun 2020 05:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JSriO90KA1bxdli8UfpZjRmxsybWO5Wh/NW0+hAqqdM=; b=o+GVT85t9b1gbzZwNOL8oOSgXJ ri96IB4Snk0Ry137vOKVgzitdKyjM1c5BKWXmBjDkyFri97JmXhhD3KiAwFgNGprYax9LAzHTxnPw abtUS9KV8owlpXJk9ECqv5fy/o1kpfl20bd8ck1rJSa64EROjd/567uO3I4+f8pSj91hqizeqfcdm nrxDuMJtQ0QcnBLgT/WSnnJl7tY5idy+HBogiISceVng1j8PG5GRTRP9sPPUJm1bex3YX1unak5na biL3dEG9B+Hya4+etQkugqlaixhOx08mjDv2b5YiTabmJLEqeYpJyQR2XsASyEbU85UkfBEfD2TRC G7UKyobQ==; Received: from [82.138.51.4] (port=52200 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jjM9s-0002Fs-5Z for dots@ietf.org; Thu, 11 Jun 2020 08:18:13 -0400 From: "Valery Smyslov" To: References: <159181529656.16063.6964178024900109434@ietfa.amsl.com> <90F43A4B-9A1E-480A-B7BF-75A93842C261@att.com> In-Reply-To: <90F43A4B-9A1E-480A-B7BF-75A93842C261@att.com> Date: Thu, 11 Jun 2020 15:18:00 +0300 Message-ID: <009901d63fea$5bd6cfb0$13846f10$@smyslov.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01D64003.812678B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL7UZrHu6prX15g4dnWpSb9MiunYAHvhvmVpnm04SA= Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [Dots] FW: Nomcom 2020-2021 Second Call For Volunteers 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 12:18:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009A_01D64003.812678B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 this message is forwarded by request of Barbara Stark, a NOMCOM 2020 = Chair. =20 Regards, Valery. =20 Begin forwarded message: From: NomCom Chair 2020 Date: June 10, 2020 at 1:55:21 PM CDT To: IETF Announcement List Cc: "ietf@ietf.org" Subject: Nomcom 2020-2021 Second Call For Volunteers =EF=BB=BFThis is the second sending of the call for volunteers for the = 2020-2021 NomCom. I wanted to mention a few updates from the previous email (sent 2 weeks = ago): - I've fixed the URL at the bottom of the email to point to = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8T= q4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEds= FcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D instead of /2019/. This was a test = to see if anyone was paying attention. Apparently, some people were. ;) - The IETF 108 registration form includes a checkbox that will let you = volunteer. You can use this instead of emailing me, when you register = for IETF 108. - I currently have 39 volunteers. Last year had 149. I need more = volunteers! -------------------------------------------------------------------------= -------- The IETF NomCom appoints people to fill the open slots on the LLC, IETF = Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random = way from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population. The details of the operation of the NomCom can be found in BCP 10 (RFC = 8713). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 = (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to = volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and=20 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the = five listed meetings. You can check your eligibility at: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_regis= tration_nomcom.py&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY= 8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3D7_9x9PPoUIa= jJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo&e=3D . If you qualify, please volunteer. Before you decide to volunteer, please = remember that anyone appointed to this NomCom will not be considered as = a candidate for any of the positions that the 2020 - 2021 NomCom is = responsible for filling. People commonly volunteer by ticking the box on IETF registration forms. = The IETF 106 form did not ask whether people were willing to volunteer. = IETF 107 did ask, but all those registrations were canceled. I have = asked the Secretariat if it is possible to get the list if volunteers = from canceled IETF 107 registrations. If that list is available, I will = contact all who are verified as eligible. But given the uncertainty of = this process, I would encourage people to volunteer directly (see the = bottom of this email for instructions). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF = meeting, and thus the positions for which this NomCom is responsible, = are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD =C3=89ric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the = General area has 1; all other areas have 2 ADs. Thus, all areas (that = have more than one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should = be completed in January 2021. The NomCom will have regularly scheduled = conference calls to ensure progress. There will be activities to collect = requirements from the community, review candidate questionnaires, review = feedback from community members about candidates, and talk to = candidates. While being a NomCom member does require some time commitment it is also = a very rewarding experience. As a member of the NomCom it is very important that you be willing and = able to attend either videoconference or in-person meetings (which may = not happen) during 14-20 November (IETF 109 - Bangkok) to conduct = interviews. Videoconference attendance will be supported whether or not = there are in-person meetings. Orientation and setting of the NomCom = schedule will be done by videoconference during the week 20-24 July = (exact time and date to be determined after NomCom membership is = finalized on July 12), the week prior to IETF 108. Being at IETF 110 = (Prague) is not essential. Please volunteer by sending me an email before 23:59 UTC June 24, 2020, = as follows: To: nomcom-chair-2020@ietf.org Subject: NomCom 2020-21 Volunteer Please include the following information in the email body: Your Full Name:=20 // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails:=20 // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone:=20 // For confirmation if selected You should expect an email response from me within 5 business days = stating whether or not you are qualified. If you don't receive this = response, please re-send your email with the tag "RESEND"" added to the = subject line. If you are not yet sure if you would like to volunteer, please consider = that NomCom members play a very important role in shaping the leadership = of the IETF. Questions by email or voice are welcome. Volunteering for = the NomCom is a great way to contribute to the IETF! You can find a detailed timeline on the NomCom web site at: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8T= q4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEds= FcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D=20 I will be publishing a more detailed target timetable, as well as = details of the randomness seeds to be used for the RFC 3797 selection = process, within the next few weeks. Thank you! Barbara Stark bs7652 at att dot com nomcom-chair-2020 at ietf dot org ------=_NextPart_000_009A_01D64003.812678B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

this message is forwarded by request of Barbara Stark, a NOMCOM 2020 = Chair.

 

Regards,

Valery.

 

Begin forwarded = message:

From: NomCom Chair 2020 = <nomcom-chair-2020@ietf.org>
Date: June 10, 2020 at = 1:55:21 PM CDT
To: IETF Announcement List = <ietf-announce@ietf.org>
Cc: "ietf@ietf.org" = <ietf@ietf.org>
Subject: Nomcom 2020-2021 Second Call = For Volunteers

=EF=BB=BFThis is the second sending of = the call for volunteers for the 2020-2021 NomCom.

I wanted to = mention a few updates from the previous email (sent 2 weeks ago):
- = I've fixed the URL at the bottom of the email to point to = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoG= zhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&a= mp;s=3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D =  instead of /2019/. This was a test to see if anyone was paying = attention. Apparently, some people were. ;)
- The IETF 108 = registration form includes a checkbox that will let you volunteer. You = can use this instead of emailing me, when you register for IETF = 108.
- I currently have 39 volunteers. Last year had 149. I need more = volunteers!
----------------------------------------------------------= -----------------------
The IETF NomCom appoints people to fill the = open slots on the LLC, IETF Trust, the IAB, and the IESG.

Ten = voting members for the NomCom are selected in a verifiably random way = from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population.

The details of the operation of the NomCom can be = found in BCP 10 (RFC 8713). RFC 3797 details the selection = algorithm.

Special for this year (and only this year), we also = have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is = eligible to volunteer:

     Members of = the IETF community must have attended at least three = of
     the last five in-person IETF = meetings in order to volunteer.

     The = five meetings are the five most recent in-person meetings = that
     ended prior to the date on which = the solicitation for NomCom
     volunteers = was submitted for distribution to the IETF = community.
     Because no IETF 107 = in-person meeting was held, for the = 2020-2021
     Nominating Committee those = five meetings are IETFs
       102 = [Montreal, Canada; July = 2018],
       103 [Bangkok, = Thailand; November = 2018],
       104 [Prague, Czech = Republic; March 2019],
       105 = [Montreal, Canada; July 2019], and =
       106 [Singapore; November = 2019].

Keep in mind that eligibility is based on in-person = attendance at the five listed meetings. You can check your eligibility = at: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_regis= tration_nomcom.py&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DL= oGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI= &s=3D7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo&e=3D = .

If you qualify, please volunteer. Before you decide to = volunteer, please remember that anyone appointed to this NomCom will not = be considered as a candidate for any of the positions that the 2020 - = 2021 NomCom is responsible for filling.

People commonly volunteer = by ticking the box on IETF registration forms. The IETF 106 form did not = ask whether people were willing to volunteer. IETF 107 did ask, but all = those registrations were canceled. I have asked the Secretariat if it is = possible to get the list if volunteers from canceled IETF 107 = registrations. If that list is available, I will contact all who are = verified as eligible. But given the uncertainty of this process, I would = encourage people to volunteer directly (see the bottom of this email for = instructions). Thank you for volunteering!

The list of people and = posts whose terms end with the March 2021 IETF meeting, and thus the = positions for which this NomCom is responsible, are

IETF = Trust:
   Joel = Halpern

LLC:
   Maja = Andjelkovic

IAB:
   Jari = Arkko
   Jeff Tantsura
   Mark = Nottingham
   Stephen Farrell
   Wes = Hardaker
   Zhenbin = Li

IESG:
   Alissa Cooper, IETF Chair/GEN = AD
   Alvaro Retana, RTG AD
   Barry = Leiba, ART AD
   Deborah Brungard, RTG = AD
   =C3=89ric Vyncke, INT = AD
   Magnus Westerlund, TSV = AD
   Roman Danyliw, SEC = AD
   Warren Kumari, OPS AD

All appointments = are for 2 years. The Routing area has 3 ADs and the General area has 1; = all other areas have 2 ADs. Thus, all areas (that have more than one AD) = have at least one continuing AD.

The primary activity for this = NomCom will begin in July 2020 and should be completed in January 2021. =  The NomCom will have regularly scheduled conference calls to = ensure progress. There will be activities to collect requirements from = the community, review candidate questionnaires, review feedback from = community members about candidates, and talk to candidates.

While = being a NomCom member does require some time commitment it is also a = very rewarding experience.

As a member of the NomCom it is very = important that you be willing and able to attend either videoconference = or in-person meetings (which may not happen) during 14-20 November (IETF = 109 - Bangkok) to conduct interviews. Videoconference attendance will be = supported whether or not there are in-person meetings. Orientation and = setting of the NomCom schedule will be done by videoconference during = the week 20-24 July (exact time and date to be determined after NomCom = membership is finalized on July 12), the week prior to IETF 108. =  Being at IETF 110 (Prague) is not essential.

Please = volunteer by sending me an email before 23:59 UTC June 24, 2020, as = follows:

To: nomcom-chair-2020@ietf.org
Subject: NomCom = 2020-21 Volunteer

Please include the following information in the = email body:

Your Full Name:
   // as you write = it on the IETF registration form

Current Primary = Affiliation:
   // Typically what goes in the Company = field
   // in the IETF Registration = Form

Emails:
  // All email addresses used to = register for the past 5 IETF meetings
  // Preferred email = address first

Telephone:
   // For = confirmation if selected

You should expect an email response from = me within 5 business days stating whether or not you are qualified. =  If you don't receive this response, please re-send your email with = the tag "RESEND"" added to the subject line.

If = you are not yet sure if you would like to volunteer, please consider = that NomCom members play a very important role in shaping the leadership = of the IETF.  Questions by email or voice are welcome. Volunteering = for the NomCom is a great way to contribute to the IETF!

You can = find a detailed timeline on the NomCom web site = at:
   https://urldefense.proofpoint.com/v2/url?u=3Dhtt= ps-3A__datatracker.ietf.org_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_H= UMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOS= HcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD= 34&e=3D

I will be publishing a more detailed target = timetable, as well as details of the randomness seeds to be used for the = RFC 3797 selection process, within the next few weeks.

Thank = you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 = at ietf dot org

------=_NextPart_000_009A_01D64003.812678B0-- From nobody Fri Jun 12 10:27:43 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AEA3A08DE; Fri, 12 Jun 2020 10:27:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159198285186.17070.17617472622862856108@ietfa.amsl.com> Date: Fri, 12 Jun 2020 10:27:31 -0700 Archived-At: Subject: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2020-06-25 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 17:27:32 -0000 The DDoS Open Threat Signaling (dots) WG will hold a virtual interim meeting on 2020-06-25 from 06:00 to 07:00 UTC. Agenda: DOTS Virtual Interim Meeting June 2020 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m583b7d2e85e9bc229e902d12aabbaa41 From nobody Fri Jun 12 22:18:47 2020 Return-Path: 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 C543D3A08CA; Fri, 12 Jun 2020 22:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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=smyslov.net 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 hYWDnIR_gN-u; Fri, 12 Jun 2020 22:18:43 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 3F5283A08C5; Fri, 12 Jun 2020 22:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nbX8d+BvJgZ0w8cw9zTlBbiL2e+aaMoEvhHvJN5ch88=; b=ABIzmMKfCRhzvmHj8vUX/Lj2gX Wt1KIlxBe3G1aThhxClloDTwJBkGJOMorCKbB4iTz9DDGAyGHqTS6jk1Sr6H0FsLGZVeCbAMFHeQP 72aY3Y6jCosufUX8pG0Vaw2L71h0h9K6N5UWWn82yQN82bB3C3htdJIpBU8gXTe1ufSCBsiZbYx+C BAsasntdfFrRfQ/BSz664gqH4HJbc4oThavST1OlhVPuDP+gUpzUrBtpR4dH142dIGlGlRb7Asvn5 6gHGlY62KH2woUpg/XdH0mNiTuVc5fSmIxoCoRHy0jTBIQntVLt74SDe9/SL5rPAVeqaY9FZ186dz hiqtUlMQ==; Received: from [185.48.37.57] (port=61378 helo=svannotebook) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jjyYw-0003TK-Gb; Sat, 13 Jun 2020 01:18:38 -0400 From: "Valery Smyslov" To: Cc: , References: <159198285186.17070.17617472622862856108@ietfa.amsl.com> In-Reply-To: <159198285186.17070.17617472622862856108@ietfa.amsl.com> Date: Sat, 13 Jun 2020 08:18:36 +0300 Message-ID: <001d01d64142$186e5820$494b0860$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: ru Thread-Index: AQFCK0ctlS1o4W7dcWlYNoc1FzkNBqn+KuCA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2020-06-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 05:18:45 -0000 Hi, more on WebEx participation: Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m583b7d2e85e9bc229e902d12aabbaa41 Meeting number: 161 684 6922 Password: WrMv7H2gBG2 More ways to join: Join by video system: Dial 1616846922@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone: 1-650-479-3208 Call-in number (US/Canada) Access code: 161 684 6922 If you want to make a presentation at the meeting, please send a request for a presentation slot to the chairs. Regards, Frank & Valery. > The DDoS Open Threat Signaling (dots) WG will hold a virtual interim meeting > on 2020-06-25 from 06:00 to 07:00 UTC. > > Agenda: > DOTS Virtual Interim Meeting June 2020 > > Information about remote participation: > https://ietf.webex.com/ietf/j.php?MTID=m583b7d2e85e9bc229e902d12aabb > aa41 > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Jun 13 00:56:02 2020 Return-Path: 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 BD3623A0A35 for ; Sat, 13 Jun 2020 00:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 ctGktmA27fqj for ; Sat, 13 Jun 2020 00:55:59 -0700 (PDT) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA883A0A32 for ; Sat, 13 Jun 2020 00:55:59 -0700 (PDT) Received: by mail-oo1-xc35.google.com with SMTP id v3so2406587oot.1 for ; Sat, 13 Jun 2020 00:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sYYBKUgwtu9xARy/XjmY2zLTC3wuFLbxw3aQnLC/wPQ=; b=ZnX3sNO6YNLmVcdP8/pbJZRNryBb6wZJK0ht6OdnpyoBSFf/iPOo6V6QABeMa9N6xB 7AIc/Rq371SAQbjGz92csLi8Txcgs9nnBG4cHnv2semSfXBPXQ95kWJ0Gcw22Ld/uWj+ 7djqgo0JnIMwG2cHxmabe5BX00QtiPOT+SUUdn0HjxYeT9ssuRcgDNAirvfGRBFR6tKm A6A4ABnxifnE4FYci809jdr2Xp52R9mRf6KvyGbjx2mGOEIdm6x57I0vtAydjCnF9nNE gX/AFj/bpU2EKSwxA6IT4AAVnE4F/o9aJGTMoCAPrjHhDACc1eXGShIfPAGO+sTjPMtZ ouXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sYYBKUgwtu9xARy/XjmY2zLTC3wuFLbxw3aQnLC/wPQ=; b=N62sX2Hmbnb3HzmEuRegzC5cAmUc09LBYnDVp+9xVoFuY0/+fasF3ygnWGgileXuKK gRe/8HSrkaIUW7ogrdeCgMaTE45hvBVLE1jn8ENYKacFrpWnu2rX14z+3blp36kFhFkz PKU1JekoRjnEz87z33x7R/TyrkjNKSnVPAoDpEJVBSB4VXBGJcjR/NPkTLQAa0bOQ72+ XdPPzcevaG4QlLTLh2RM093/vGaUHXsA/b5dvtsCT6R0o9UQRaNTEsuNtPbACugyznt3 VOeu7/1Y4huOAhCG6juEiMOu3UM7LibjtgSoQMrWo9PjLTF8nMy+F1nLIunbJUPv01lW B+zg== X-Gm-Message-State: AOAM531lwLDUgilzLE7lxEFFvKwbU55jwwVzP0fz5Yy3BFGZkwSF8eJt yrYpNXMNCvrdbKi0ni+/Gv8JPQE5PaaCgFSuRotqD1Ub X-Google-Smtp-Source: ABdhPJzCA7VzjvFLlpadqvij9HkOR3aiFhXcvffeLWMm1nM0N4amWsiotvpaHhntE1DwdhO/92b/BwMl9ZM9njCwk8o= X-Received: by 2002:a4a:45d5:: with SMTP id y204mr13967123ooa.73.1592034958537; Sat, 13 Jun 2020 00:55:58 -0700 (PDT) MIME-Version: 1.0 From: H Y Date: Sat, 13 Jun 2020 16:55:49 +0900 Message-ID: To: dots Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Dots] Options on how to move forward with telemetry use case draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 07:56:01 -0000 Hi all, We submitted DOTS telemetry use case draft based on comments from WG at IETF106. https://datatracker.ietf.org/doc/draft-hayashi-dots-telemetry-use-cases/ https://datatracker.ietf.org/doc/minutes-106-dots/ We considered some options on how to move forward with the draft as below. Opt 1. Require WG adoption after addressing comments from WG. Opt 2. Add a high-level use case description to the DOTS Telemetry draft. (e.g. Appendix) We prefer Opt 1, but no problem with Opt 2. Please tell me your preference, or other options if any. Thanks, Yuhei -- ---------------------------------- Yuuhei HAYASHI 08065300884 yuuhei.hayashi@gmail.com iehuuy_0220@docomo.ne.jp ---------------------------------- From nobody Mon Jun 15 00:17:18 2020 Return-Path: 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 627E43A0A6A for ; Mon, 15 Jun 2020 00:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 vgLfFTfNobUI for ; Mon, 15 Jun 2020 00:17:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB99F3A0992 for ; Mon, 15 Jun 2020 00:17:14 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 49ljMF2gWtz1yDZ; Mon, 15 Jun 2020 09:17:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1592205433; bh=dMqpSXQ04vNgUIP+6J7A9O7fUtCzPmaWv1pfRDUOxVk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gVsjxHG4eDpuhfjjD2vDSgCMEhZ8573PZuvS5GxgT3K+Gqq10OKYHz3EkOW7Xzdgl 2PFhS4KGY2e9kYcw9Ah9lpV2nRhJSaO9nDUkdwJCnS14g+FM4dH4eZKSdIBcPCVVhU wrU5mGdxH2+OMjcYZIUgQwAHCgSVBX6w3vlayxA0VlFlH79nUCpty0/yarfweMoJ4E USjFUYGIqCjg73HeRHZvzDlacUhZn01MbgCqla7fbk7jGnSBICXXS4fIyvmYRc2GqX t4/eoknBsZgBaNqYf68F3vSLmw1BTWGqqp8ZMqBboOMG40sCimW6vD0zJNxn2sYhDD uvS/GaFLDPB5A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 49ljMF221bz1xyZ; Mon, 15 Jun 2020 09:17:13 +0200 (CEST) From: To: H Y , dots Thread-Topic: [Dots] Options on how to move forward with telemetry use case draft Thread-Index: AQHWQVgZIAFJ6nFTqkCzG6gFNFY3H6jZRihA Date: Mon, 15 Jun 2020 07:17:12 +0000 Message-ID: <27156_1592205433_5EE72079_27156_117_1_787AE7BB302AE849A7480A190F8B9330314DE0B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Options on how to move forward with telemetry use case draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 07:17:16 -0000 Hi Yuhei, all, I support your option 1.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de H Y > Envoy=E9=A0: samedi 13 juin 2020 09:56 > =C0=A0: dots > Objet=A0: [Dots] Options on how to move forward with telemetry use case d= raft >=20 > Hi all, >=20 > We submitted DOTS telemetry use case draft based on comments from WG at > IETF106. > https://datatracker.ietf.org/doc/draft-hayashi-dots-telemetry-use-cases/ > https://datatracker.ietf.org/doc/minutes-106-dots/ >=20 > We considered some options on how to move forward with the draft as below. >=20 > Opt 1. Require WG adoption after addressing comments from WG. > Opt 2. Add a high-level use case description to the DOTS Telemetry > draft. (e.g. Appendix) >=20 > We prefer Opt 1, but no problem with Opt 2. > Please tell me your preference, or other options if any. >=20 > Thanks, > Yuhei >=20 > -- > ---------------------------------- > Yuuhei HAYASHI > 08065300884 > yuuhei.hayashi@gmail.com > iehuuy_0220@docomo.ne.jp > ---------------------------------- >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Mon Jun 15 00:39:17 2020 Return-Path: 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 8062E3A0A96 for ; Mon, 15 Jun 2020 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 JimFKjNyJIPj for ; Mon, 15 Jun 2020 00:39:13 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 231583A0A94 for ; Mon, 15 Jun 2020 00:39:11 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee15ee72576968-88be2; Mon, 15 Jun 2020 15:38:30 +0800 (CST) X-RM-TRANSID: 2ee15ee72576968-88be2 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[10.2.49.172]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5ee72574636-ac230; Mon, 15 Jun 2020 15:38:28 +0800 (CST) X-RM-TRANSID: 2eea5ee72574636-ac230 Date: Mon, 15 Jun 2020 15:38:37 +0800 From: "Meiling Chen" To: "H Y" , dots References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.115[cn] Mime-Version: 1.0 Message-ID: <202006151538372599791@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart241743087558_=----" Archived-At: Subject: Re: [Dots] Options on how to move forward with telemetry use case draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 07:39:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart241743087558_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgWXVoZWksIGFsbCwNCg0KSSBzdXBwb3J0ICBvcHRpb24gMS4NCg0KVGhhbmtzLA0KTWVpbGlu Zy4NCg0KRnJvbTogSCBZDQpEYXRlOiAyMDIwLTA2LTEzIDE1OjU1DQpUbzogZG90cw0KU3ViamVj dDogW0RvdHNdIE9wdGlvbnMgb24gaG93IHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRlbGVtZXRyeSB1 c2UgY2FzZSBkcmFmdA0KSGkgYWxsLA0KIA0KV2Ugc3VibWl0dGVkIERPVFMgdGVsZW1ldHJ5IHVz ZSBjYXNlIGRyYWZ0IGJhc2VkIG9uIGNvbW1lbnRzIGZyb20gV0cgYXQgSUVURjEwNi4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhheWFzaGktZG90cy10ZWxlbWV0cnkt dXNlLWNhc2VzLw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMDYt ZG90cy8NCiANCldlIGNvbnNpZGVyZWQgc29tZSBvcHRpb25zIG9uIGhvdyB0byBtb3ZlIGZvcndh cmQgd2l0aCB0aGUgZHJhZnQgYXMgYmVsb3cuDQogDQpPcHQgMS4gUmVxdWlyZSBXRyBhZG9wdGlv biBhZnRlciBhZGRyZXNzaW5nIGNvbW1lbnRzIGZyb20gV0cuDQpPcHQgMi4gQWRkIGEgaGlnaC1s ZXZlbCB1c2UgY2FzZSBkZXNjcmlwdGlvbiB0byB0aGUgRE9UUyBUZWxlbWV0cnkNCmRyYWZ0LiAo ZS5nLiBBcHBlbmRpeCkNCiANCldlIHByZWZlciBPcHQgMSwgYnV0IG5vIHByb2JsZW0gd2l0aCBP cHQgMi4NClBsZWFzZSB0ZWxsIG1lIHlvdXIgcHJlZmVyZW5jZSwgb3Igb3RoZXIgb3B0aW9ucyBp ZiBhbnkuDQogDQpUaGFua3MsDQpZdWhlaQ0KIA0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpZdXVoZWkgSEFZQVNISQ0KMDgwNjUzMDA4ODQNCnl1dWhlaS5oYXlhc2hp QGdtYWlsLmNvbQ0KaWVodXV5XzAyMjBAZG9jb21vLm5lLmpwDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KIA0K ------=_001_NextPart241743087558_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here is an update for this work conducted in core WG:

 

=B7         A second core interim meeting dedicated to the DOTS u= se case was organized last week. The minutes can be a seen at: https://datatracker.ietf.org/doc/minutes-interim-2020-core-06-202006101600/=

=B7         The slides are available at: https://datatracker.ietf.org/meeting/interim-2020-core-06/materials/slides-= interim-2020-core-06-sessa-coap-block-wise-transfer-options-for-faster-tran= smission

=B7         The plan is to target a call for adoption right after= the IETF meeting.

=B7         The updated version of the block-wise spec was releas= ed early this week: https:= //tools.ietf.org/html/draft-bosh-core-new-block-04

=B7         As mentioned last time, we don’t plan to add an= y normative text to this draft to avoid blocking the publication of the tel= emetry spec.

FWIW, we do use the following language in the draft. N= ote also, that we have considered other means to minimize the size of the m= essages (e.g. attack mapping).

 

=3D=3D=3D=3D=3D=3D

4.5.  Block-wise Transfer

 

   DOTS clients can use Block-wise transfer [RFC795= 9] with the

   recommendation detailed in Section 4.4.2 of [RFC= 8782] to control the

   size of a response when the data to be returned = does not fit within a

   single datagram.

 

   DOTS clients can also use CoAP Block1 Option in = a PUT request (see

   Section 2.5 of [RFC7959]) to initiate large tran= sfers, but these

   Block1 transfers will fail if the inbound "= pipe" is running full, so

   consideration needs to be made to try to fit thi= s PUT into a single

   transfer, or to separate out the PUT into severa= l discrete PUTs where

   each of them fits into a single packet.

 

   Block3 and Block 4 Options that are similar to t= he CoAP Block1 and

   Block2 Options, but enable faster transmissions = of big blocks of data

   with less packet interchanges, are defined in

   [I-D.bosh-core-new-block].  DOTS implementa= tions can consider the use

   of Block3 and Block 4 Options.=

=3D=3D=3D=3D=3D=3D

 

Cheers,

Jon & Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : vendredi 29 mai 2020 15:13
=C0 : dots@ietf.org
Cc : Jon Shallow (supjps-ietf@jpshallow.com)
Objet : Re: [Dots] [core] Large asynchronous notifications unde= r DDoS: New BLOCK Option?

 

Hi all,

 

Please find below an update about this DOTS telemetry issue:

 

=B7         A proposal to handle the issue was made: https:= //tools.ietf.org/html/draft-bosh-core-new-block-00.

=B7         The core wg dedicated an interim meeting to discuss t= he proposal (May, 13).

o   The slides presented in the meeting ca be seen here: https://datatracker.ietf.org/meeting/interim-2020-core-04/materials/slides-= interim-2020-core-04-sessa-new-coap-block-wise-transfer-options-draft-bosh-= core-new-block.

o   The minutes can be seen at: https://datatracker.ietf.org/doc/minutes-interim-2020-core-04-202005131600/= .   

=B7         An updated version to address the comments received f= rom the core wg (and especially during the interim) is available at: https:= //tools.ietf.org/html/draft-bosh-core-new-block-01.

=B7         The current plan is to avoid adding a normative depen= dency to the telemetry spec.

 

We will report back to the WG as appropriate.

 

Cheers,

Jon & Med

 

De : core= [mailto:core-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : mardi 7 avril 2020 13= :11
=C0 : core@ietf.org
Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org
Objet : [core] Large asynchronous notifications under DDoS: New= BLOCK Option?

 

Hi all,

 

= We are using Observe to receive notifications during attack events. These n= otifications are set as NON messages for reasons specific to DDoS condition= s.

=  

= With DDoS telemetry information included (see draft-ietf-dots-telemetry), a= notification may not fit one single message. The use of BLOCK2 is not conv= enient during attack times. A full description of the issue is described here: https://mailarch= ive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/

=  

= We are considering some mechanisms to solve this issue. One of them is to d= efine a new BLOCK option (similar to BLOCK2) that does not require the obse= rver to send a GET to receive the next fragment. The server will send all the fragments. The observer will follow a SACK-li= ke approach to request retransmission of missing fragments.

=  

= Please let us know whether you think this is a generic issue that should be= solved at the CoAP or not. Suggestions are welcome.

=  

= Thank you.

=  

= Cheers,

= Jon & Med 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E3C5EOPEXCAUBMA2corp_-- From nobody Fri Jun 19 15:17:27 2020 Return-Path: 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 5E9B43A0EFF for ; Fri, 19 Jun 2020 15:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=akamai.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 5nyPUns1Wy6H for ; Fri, 19 Jun 2020 15:17:23 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 14EB13A0F12 for ; Fri, 19 Jun 2020 15:17:22 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05JM8jWI023631 for ; Fri, 19 Jun 2020 23:17:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=WDBJxQFA5Ffx1tyYDY3XTG/gJjgS7oipFuYWVxdS8qU=; b=Z99ZhUHpyqyFNSDJKnQaBa8+ZT8VOYWAS1U4MsS70vAw7VxLSzIJKmmX93D6oLklMM/+ OCMBNI/zncAC7Tytazw0fFBvMjDtp6Bxi8jcyc5bt17OLmE2WSEpvi0CeSdwZUnbDH6X kOKAPh3lri9c/dWAaMuXPGoxJC52zWhPesHxYHv40IKpcVEwJdaq+Bwjb/SCFwvuPH9S KzkWZnx8dtadNne7aB6+D+P1xPG+MmljUst9R1S0wByDBYiZYWvVbRDlkAgENoU61Qxj hEAsbgTdtt5rZmFf+DR2ZzCcfXywOOBnXmv2Qdp2XJx4z6+7aN54Oj5iX8prVEOAwO/4 HA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 31rvhdc4t4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 19 Jun 2020 23:17:22 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05JM5Won021241 for ; Fri, 19 Jun 2020 18:17:21 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 31qjmbx55g-1 for ; Fri, 19 Jun 2020 18:17:21 -0400 Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id CC4A13A656 for ; Fri, 19 Jun 2020 22:17:20 +0000 (GMT) Date: Fri, 19 Jun 2020 15:17:20 -0700 From: Benjamin Kaduk To: dots@ietf.org Message-ID: <20200619221719.GG20623@akamai.com> References: <9cd91c24-c730-22a4-7aa0-baf61613b3ce@huitema.net> <95dd02c92b32472d9cab0dd47b98c637@usma1ex-dag1mb5.msg.corp.akamai.com> <9c2e300c30f74d1794d11cf4334ea07b@usma1ex-dag1mb5.msg.corp.akamai.com> <2c40f3d9-fa40-9834-ac30-36bc9a1a6303@huitema.net> <20200619215324.GF20623@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200619215324.GF20623@akamai.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_22:2020-06-19, 2020-06-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 adultscore=0 mlxlogscore=399 mlxscore=0 phishscore=0 suspectscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190155 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_22:2020-06-19, 2020-06-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 mlxlogscore=357 mlxscore=0 lowpriorityscore=0 bulkscore=0 cotscore=-2147483648 phishscore=0 adultscore=0 spamscore=0 priorityscore=1501 impostorscore=0 clxscore=1011 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190155 Archived-At: Subject: [Dots] Fwd: Is the invariants draft really standards track? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 22:17:25 -0000 Happening over on quic@ietf.org, if there is anything interesting to note. -Ben On Fri, Jun 19, 2020 at 02:53:25PM -0700, Benjamin Kaduk wrote: > On Fri, Jun 19, 2020 at 02:48:48PM -0700, Christian Huitema wrote: > > When under DOS attack, you want to "minimize blowback", i.e., as much as > > possible avoid generating packets in response to attack traffic. So, > > yes, a server may choose to not send stateless resets to anyone when > > under attack; in fact, my recommendation would be that a server SHOULD > > NOT send stateless resets to anyone when under attack. > > > > That said, Igor raised an interesting point about return traffic. It > > would be very nice if DOS protection boxes could distinguish between > > "validated traffic" that the server presumably intends to process, and > > "unsolicited traffic" that will just consume resource. The box can then > > reserve some share of the resource for validated traffic, and place the > > rest of the traffic in a lower priority queue. Fine, but there needs to > > be a test. The classic test is that incoming traffic is "validated" if > > the protection box can match it with return traffic coming from the > > server -- for some definition of matching. > > > > From that point of view, stateless reset is definitely not helpful. But > > problematic traffic goes beyond that. The server will reply to a > > client's initial with a server's initial packet. Does that validate the > > response traffic? OK, maybe the protection box can programmed to only > > validate traffic if it sees 1RTT packets. But many servers will send > > 1-RTT packets as 0.5 RTT. Does that validate the response traffic? > > > > We might say that traffic is validated when the handshake is confirmed, > > but the protection box does not understand the TLS handshake, it just > > sees packet types and packet sizes. It cannot distinguish between 0.5RTT > > data and 1RTT data, and thus the closest approximation of "validation" > > would be seeing more than an initial window worth of traffic coming back > > from the server. That does not sound great. > > > > On the other hand, things get much better if the server under attack can > > adopt a defensive posture and help the DOS protection box do its job. > > Suppose that a server can detect that it is under attack -- or be > > explicitly configured so. The simplest defensive posture would be to (1) > > disable stateless reset and (2) not send any 0.5RTT packet, including in > > response to 0-RTT. The protection boxes can at that point take the 1-RTT > > packets from the server as indicating validation. > > > > Maybe we should specify that. > > It might also be an interesting thought experiment to see what > kind of things the QUIC server could send to the DoS protection box if > the QUIC server acts as a DOTS (RFCs 8782 and 8783) client to a DOTS > server controlling the DoS protection box. > > -Ben > From nobody Sun Jun 21 11:28:47 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3858E3A07DB; Sun, 21 Jun 2020 11:28:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-dots-signal-filter-control@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , Liang Xia X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159276412220.8151.4554809718487944981@ietfa.amsl.com> Date: Sun, 21 Jun 2020 11:28:42 -0700 Archived-At: Subject: [Dots] Murray Kucherawy's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 18:28:42 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-dots-signal-filter-control-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some minor stuff only: Section 1.1: OLD: A typical case is a conflict between filtering rules installed by a DOTS client and the mitigation actions of a DDoS mitigator. Such case is a DOTS client which configures during 'idle' time (i.e., no mitigation is active) some filtering rules using the DOTS data channel protocol to permit traffic from accept-listed sources, but during a volumetric DDoS attack the DDoS mitigator identifies the source addresses/prefixes in the accept-listed filtering rules are attacking the target. For example, an attacker can spoof the IP addresses of accept-listed sources to generate attack traffic or the attacker can compromise the accept-listed sources and program them to launch a DDoS attack. NEW: A typical case is a conflict between filtering rules installed by a DOTS client and the mitigation actions of a DDoS mitigator. Consider, for instance, a DOTS client that configures during 'idle' time (i.e., no mitigation is active) some filtering rules using the DOTS data channel protocol to permit traffic from accept-listed sources. However, during a volumetric DDoS attack the DDoS mitigator identifies the source addresses/prefixes in the accept-listed filtering rules are attacking the target. For example, an attacker can spoof the IP addresses of accept-listed sources to generate attack traffic or the attacker can compromise the accept-listed sources and program them to launch a DDoS attack. Section 1.2: * "An augment to the DOTS signal channel ..." -- s/augment/amendment/ ("augment" isn't a thing, it's an action) Section 3.2.1: * Although this section declares the acronym "ACE" for "Access Control Entry", that acronym is used nowhere else in the document. * "... notifies that DOTS client with the change ..." -- s/with/of, I think? Section 6: * "... does not allow to create new filtering rules ..." -- s/to create/creation of/ * "... entitled to access only to resources ..." -- s/only to/only those/ From nobody Sun Jun 21 22:52:22 2020 Return-Path: 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 A01513A092B; Sun, 21 Jun 2020 22:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 xX_pTxk4u24l; Sun, 21 Jun 2020 22:52:08 -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 4B2533A0925; Sun, 21 Jun 2020 22:52:08 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar27.francetelecom.fr (ESMTP service) with ESMTPS id 49qz7p3xD2z2xb4; Mon, 22 Jun 2020 07:52:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1592805126; bh=NLKuFat6gQqql966jKGYC1oThY39NaDsoIH4WBK4hMU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=b2e9ATMbi17IqhhvpghZYwxbMSwh5mj414jL8wEd6DvA1JpTsqER17nQrpgjmdp2G vSKFf6El3bXfRCsBTQiqR2fGgMARj2F/0EHxc97GoZtpsP0BCdPBv+KIYOkjMBEBZo oU0BoITyMex9hu+8cGKWGNpJni6KARYK61hGFzXkDoZEcuAj1zZga+mBrlDcp344Bq Hmi2/LmNGXwD3jDsV45XWxvsAHuieINuLy9rJtRF+6ZLq+tLPL+q9NB4DMdIQbYmX7 EoDhxtT/ZSqZKDETEuZRUdOO/gstiIzV91S2U0fSRARZskBrZV8BTWAot4B9YbmNBK TQDd5eMv/Tvsw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 49qz7p2FbVzCqk7; Mon, 22 Jun 2020 07:52:06 +0200 (CEST) From: To: Murray Kucherawy , The IESG CC: "draft-ietf-dots-signal-filter-control@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov , Liang Xia Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) Thread-Index: AQHWR/nMxCKJiZikB0+Q0v+dxNPMBKjkIfEw Date: Mon, 22 Jun 2020 05:52:05 +0000 Message-ID: <8418_1592805126_5EF04706_8418_303_1_787AE7BB302AE849A7480A190F8B9330314E4A4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159276412220.8151.4554809718487944981@ietfa.amsl.com> In-Reply-To: <159276412220.8151.4554809718487944981@ietfa.amsl.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Murray Kucherawy's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 05:52:12 -0000 SGkgTXVycmF5LCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KSSBpbXBsZW1lbnRl ZCBhbG1vc3QgYWxsIHlvdXIgc3VnZ2VzdGlvbnMuIA0KDQpBbiB1cGRhdGVkIHZlcnNpb24gY2Fu IGJlIHNlZW4gYXQ6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvZmlsdGVyLWNvbnRy b2wvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1maWx0ZXItY29udHJvbC0wNi50 eHQgDQoNCkZXSVcsIGEgZGlmZiBpcyBhdmFpbGFibGUgaGVyZTogaHR0cHM6Ly9naXRodWIuY29t L2JvdWNhZGFpci9maWx0ZXItY29udHJvbC9ibG9iL21hc3Rlci9JRVNHLVJldmlldyUyME11cnJh eS5wZGYNCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IE11cnJheSBLdWNoZXJhd3kgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBp ZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBkaW1hbmNoZSAyMSBqdWluIDIwMjAgMjA6MjkNCj4gw4DC oDogVGhlIElFU0cNCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1maWx0ZXItY29udHJv bEBpZXRmLm9yZzsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRvdHNAaWV0Zi5vcmc7IFZhbGVy eSBTbXlzbG92OyBMaWFuZyBYaWENCj4gT2JqZXTCoDogTXVycmF5IEt1Y2hlcmF3eSdzIE5vIE9i amVjdGlvbiBvbiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci0NCj4gY29udHJvbC0wNjog KHdpdGggQ09NTUVOVCkNCj4gDQo+IE11cnJheSBLdWNoZXJhd3kgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmls dGVyLWNvbnRyb2wtMDY6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+ IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVy LWNvbnRyb2wvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCj4gU29tZSBtaW5vciBzdHVmZiBvbmx5Og0KPiANCj4gU2VjdGlvbiAx LjE6DQo+IA0KPiBPTEQ6DQo+IA0KPiAgICBBIHR5cGljYWwgY2FzZSBpcyBhIGNvbmZsaWN0IGJl dHdlZW4gZmlsdGVyaW5nIHJ1bGVzIGluc3RhbGxlZCBieSBhDQo+ICAgIERPVFMgY2xpZW50IGFu ZCB0aGUgbWl0aWdhdGlvbiBhY3Rpb25zIG9mIGEgRERvUyBtaXRpZ2F0b3IuICBTdWNoDQo+ICAg IGNhc2UgaXMgYSBET1RTIGNsaWVudCB3aGljaCBjb25maWd1cmVzIGR1cmluZyAnaWRsZScgdGlt ZSAoaS5lLiwgbm8NCj4gICAgbWl0aWdhdGlvbiBpcyBhY3RpdmUpIHNvbWUgZmlsdGVyaW5nIHJ1 bGVzIHVzaW5nIHRoZSBET1RTIGRhdGENCj4gICAgY2hhbm5lbCBwcm90b2NvbCB0byBwZXJtaXQg dHJhZmZpYyBmcm9tIGFjY2VwdC1saXN0ZWQgc291cmNlcywgYnV0DQo+ICAgIGR1cmluZyBhIHZv bHVtZXRyaWMgRERvUyBhdHRhY2sgdGhlIEREb1MgbWl0aWdhdG9yIGlkZW50aWZpZXMgdGhlDQo+ ICAgIHNvdXJjZSBhZGRyZXNzZXMvcHJlZml4ZXMgaW4gdGhlIGFjY2VwdC1saXN0ZWQgZmlsdGVy aW5nIHJ1bGVzIGFyZQ0KPiAgICBhdHRhY2tpbmcgdGhlIHRhcmdldC4gIEZvciBleGFtcGxlLCBh biBhdHRhY2tlciBjYW4gc3Bvb2YgdGhlIElQDQo+ICAgIGFkZHJlc3NlcyBvZiBhY2NlcHQtbGlz dGVkIHNvdXJjZXMgdG8gZ2VuZXJhdGUgYXR0YWNrIHRyYWZmaWMgb3IgdGhlDQo+ICAgIGF0dGFj a2VyIGNhbiBjb21wcm9taXNlIHRoZSBhY2NlcHQtbGlzdGVkIHNvdXJjZXMgYW5kIHByb2dyYW0g dGhlbSB0bw0KPiAgICBsYXVuY2ggYSBERG9TIGF0dGFjay4NCj4gDQo+IE5FVzoNCj4gDQo+ICAg IEEgdHlwaWNhbCBjYXNlIGlzIGEgY29uZmxpY3QgYmV0d2VlbiBmaWx0ZXJpbmcgcnVsZXMgaW5z dGFsbGVkIGJ5IGENCj4gICAgRE9UUyBjbGllbnQgYW5kIHRoZSBtaXRpZ2F0aW9uIGFjdGlvbnMg b2YgYSBERG9TIG1pdGlnYXRvci4gIENvbnNpZGVyLA0KPiAgICBmb3IgaW5zdGFuY2UsIGEgRE9U UyBjbGllbnQgdGhhdCBjb25maWd1cmVzIGR1cmluZyAnaWRsZScgdGltZSAoaS5lLiwgbm8NCj4g ICAgbWl0aWdhdGlvbiBpcyBhY3RpdmUpIHNvbWUgZmlsdGVyaW5nIHJ1bGVzIHVzaW5nIHRoZSBE T1RTIGRhdGENCj4gICAgY2hhbm5lbCBwcm90b2NvbCB0byBwZXJtaXQgdHJhZmZpYyBmcm9tIGFj Y2VwdC1saXN0ZWQgc291cmNlcy4gIEhvd2V2ZXIsDQo+ICAgIGR1cmluZyBhIHZvbHVtZXRyaWMg RERvUyBhdHRhY2sgdGhlIEREb1MgbWl0aWdhdG9yIGlkZW50aWZpZXMgdGhlDQo+ICAgIHNvdXJj ZSBhZGRyZXNzZXMvcHJlZml4ZXMgaW4gdGhlIGFjY2VwdC1saXN0ZWQgZmlsdGVyaW5nIHJ1bGVz IGFyZQ0KPiAgICBhdHRhY2tpbmcgdGhlIHRhcmdldC4gIEZvciBleGFtcGxlLCBhbiBhdHRhY2tl ciBjYW4gc3Bvb2YgdGhlIElQDQo+ICAgIGFkZHJlc3NlcyBvZiBhY2NlcHQtbGlzdGVkIHNvdXJj ZXMgdG8gZ2VuZXJhdGUgYXR0YWNrIHRyYWZmaWMgb3IgdGhlDQo+ICAgIGF0dGFja2VyIGNhbiBj b21wcm9taXNlIHRoZSBhY2NlcHQtbGlzdGVkIHNvdXJjZXMgYW5kIHByb2dyYW0gdGhlbSB0bw0K PiAgICBsYXVuY2ggYSBERG9TIGF0dGFjay4NCj4gDQo+IFNlY3Rpb24gMS4yOg0KPiANCj4gKiAi QW4gYXVnbWVudCB0byB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCAuLi4iIC0tIHMvYXVnbWVudC9h bWVuZG1lbnQvDQo+ICgiYXVnbWVudCIgaXNuJ3QgYSB0aGluZywgaXQncyBhbiBhY3Rpb24pDQo+ IA0KPiBTZWN0aW9uIDMuMi4xOg0KPiANCj4gKiBBbHRob3VnaCB0aGlzIHNlY3Rpb24gZGVjbGFy ZXMgdGhlIGFjcm9ueW0gIkFDRSIgZm9yICJBY2Nlc3MgQ29udHJvbA0KPiBFbnRyeSIsDQo+IHRo YXQgYWNyb255bSBpcyB1c2VkIG5vd2hlcmUgZWxzZSBpbiB0aGUgZG9jdW1lbnQuDQo+IA0KPiAq ICIuLi4gbm90aWZpZXMgdGhhdCBET1RTIGNsaWVudCB3aXRoIHRoZSBjaGFuZ2UgLi4uIiAtLSBz L3dpdGgvb2YsIEkNCj4gdGhpbms/DQo+IA0KPiBTZWN0aW9uIDY6DQo+IA0KPiAqICIuLi4gZG9l cyBub3QgYWxsb3cgdG8gY3JlYXRlIG5ldyBmaWx0ZXJpbmcgcnVsZXMgLi4uIiAtLSBzL3RvDQo+ IGNyZWF0ZS9jcmVhdGlvbiBvZi8NCj4gDQo+ICogIi4uLiBlbnRpdGxlZCB0byBhY2Nlc3Mgb25s eSB0byByZXNvdXJjZXMgLi4uIiAtLSBzL29ubHkgdG8vb25seSB0aG9zZS8NCj4gDQo+IA0KDQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Jun 22 01:32:13 2020 Return-Path: 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 591283A0BA9; Mon, 22 Jun 2020 01:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net 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 IKdk1pdqvOlE; Mon, 22 Jun 2020 01:32:09 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 B71D63A095F; Mon, 22 Jun 2020 01:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6iz4hvpOXOXGy9L3jmp8/IOuFJ8D4OLO0XGmPc0uk4s=; b=msFh9ScBTAflJP1QlhEl5M/5uh 438U88k7Dimr68Jl1/fOjTTgia3ooHZl6bDECSy0phRHozsf5U6f/s3tvsGgEZnn4euXWO69BxEF/ S9u6rO8GiHOvcIUChdVUITHKMWLGs+WBiD0nQWHjqX8jZrV9JzULcQc0vjOXAoSHt+3BfOeQBOMlV 4G7GjaQQz1La6HOL34gzv203l2jUGHK1Lg5N0lGZxzKBPBqpCYqVYsMFSMPwi1Gcrnom5/fEQVzpP AFzOxCEr+900E7UHiJI17RXzgVz/huVNqmeY5jYS7VJlzeww+wwrbJTITSl1AsTzwPPjsx6Ihos86 dbswIjZA==; Received: from [82.138.51.3] (port=60664 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jnHs7-0006TC-OP; Mon, 22 Jun 2020 04:32:08 -0400 From: "Valery Smyslov" To: Cc: , References: <159198285186.17070.17617472622862856108@ietfa.amsl.com> <001d01d64142$186e5820$494b0860$@smyslov.net> In-Reply-To: <001d01d64142$186e5820$494b0860$@smyslov.net> Date: Mon, 22 Jun 2020 11:32:05 +0300 Message-ID: <09c301d6486f$9e5b1f70$db115e50$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCK0ctlS1o4W7dcWlYNoc1FzkNBgG7UWUfqf6rReA= Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2020-06-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 08:32:11 -0000 Hi, this is a reminder that DOTS WG is having a virtual interim meeting this week on Thursday 25th June 2020 6:00-7:00 UTC. Presenters, please upload your slides to the datatracker or send them to the chairs before the meeting starts. Meeting details: WebEx: https://ietf.webex.com/ietf/j.php?MTID=m583b7d2e85e9bc229e902d12aabbaa41 Jabber: xmpp:dots@jabber.ietf.org?join Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-dots-01-dots?useMonospaceFont=true Slides: https://datatracker.ietf.org/meeting/interim-2020-dots-01/agenda/dots-drafts.pdf Agenda: 1. Administrivia and agenda bashing - 5 min (Chairs) 2. Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry status update (draft-ietf-dots-telemetry-08) - 25 min (Med, Tiru) 3. Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) status update (draft-ietf-dots-multihoming-04) - 5 min (Med, Tiru) 4. Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry (draft-hayashi-dots-telemetry-use-cases-00) - 5 min (Yuhei) 5. A method for dots server deployment (draft-chen-dots-server-hierarchical-deployment-02) - 5 min (Meiling) 6. Open Mic - 10 min 7. Wrapping up - 5 min (Chairs) More on WebEx participation: Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m583b7d2e85e9bc229e902d12aabbaa41 Meeting number: 161 684 6922 Password: WrMv7H2gBG2 More ways to join: Join by video system: Dial 1616846922@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone: 1-650-479-3208 Call-in number (US/Canada) Access code: 161 684 6922 Regards, Frank & Valery. From nobody Mon Jun 22 14:59:07 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099B43A11EC; Mon, 22 Jun 2020 14:59:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-dots-signal-filter-control@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , Liang Xia , frank.xialiang@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159286314501.18862.4075221884152241102@ietfa.amsl.com> Date: Mon, 22 Jun 2020 14:59:05 -0700 Archived-At: Subject: [Dots] Roman Danyliw's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 21:59:05 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-dots-signal-filter-control-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for responding to the SECDIR review (and thanks to Shawn Emery for conducting the review). ** Is there a reason why the meta-data header in this document doesn’t note this as an update to RFC8782 (especially since it is updating an operational gap)? ** Minor editorial nits: -- Section 4.1. Editorial. s/Some time/Sometime/ -- Section 5.1. Recommend against hard-coding the IANA registry URL From nobody Mon Jun 22 22:44:01 2020 Return-Path: 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 D366A3A1779; Mon, 22 Jun 2020 22:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 1LEdo4_Zz_pZ; Mon, 22 Jun 2020 22:43:58 -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 194DD3A1778; Mon, 22 Jun 2020 22:43:58 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 49rZvw2xT8z5w14; Tue, 23 Jun 2020 07:43:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1592891036; bh=3aFGAHG+ZQeCdvOccSB2rtMKSP2zCPv2cRk0R5//ZjE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FwnwOtmnowyavWgMeuIhQlyrYbZ0BR3lrvP78gFi7ytcUDpOREvxrp9r95eE5P7mQ KM2psbnuyj2Vc/u7qm6cIf9mA9y9gVMiak3VolMIye4g0MoqI/UlaJ5L28rpQTOMhi ZA1yCd/QvOnncK/KyDsOrBf4hxlZzq3LyCGDvbzMDMKIUbxhfc3gwOpUTdYOmYVD2Y Gu4MVWPgLvg2QxYh1Z9YMkesL4EKX2JFZSNW/zSUqeVqUsb2UnNXtHbk/EpWBLsLs1 LEu3wr8rmEzyqJHRVtYB/nCV9Fn2q/g78+B5ZRlLrDTRnpxdqtSp2+quPZl+QccMz3 J//usihpD+QIQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 49rZvw1M9BzBrLp; Tue, 23 Jun 2020 07:43:56 +0200 (CEST) From: To: Roman Danyliw , The IESG CC: "draft-ietf-dots-signal-filter-control@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov , Liang Xia Thread-Topic: Roman Danyliw's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) Thread-Index: AQHWSOBaW7d6UebQiEySKZjU2pDDdKjlqmKw Date: Tue, 23 Jun 2020 05:43:54 +0000 Message-ID: <10383_1592891036_5EF1969C_10383_179_8_787AE7BB302AE849A7480A190F8B9330314E56D2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159286314501.18862.4075221884152241102@ietfa.amsl.com> In-Reply-To: <159286314501.18862.4075221884152241102@ietfa.amsl.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Roman Danyliw's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 05:44:00 -0000 SGkgUm9tYW4sIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpQbGVhc2Ugc2VlIGlu bGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0 Zi5vcmddDQo+IEVudm95w6nCoDogbHVuZGkgMjIganVpbiAyMDIwIDIzOjU5DQo+IMOAwqA6IFRo ZSBJRVNHDQo+IENjwqA6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVyLWNvbnRyb2xAaWV0 Zi5vcmc7IGRvdHMtY2hhaXJzQGlldGYub3JnOw0KPiBkb3RzQGlldGYub3JnOyBWYWxlcnkgU215 c2xvdjsgTGlhbmcgWGlhOyBmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tDQo+IE9iamV0wqA6IFJv bWFuIERhbnlsaXcncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1maWx0 ZXItDQo+IGNvbnRyb2wtMDY6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBSb21hbiBEYW55bGl3IGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRm LWRvdHMtc2lnbmFsLWZpbHRlci1jb250cm9sLTA2OiBObyBPYmplY3Rpb24NCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhhbmtzIGZvciBy ZXNwb25kaW5nIHRvIHRoZSBTRUNESVIgcmV2aWV3IChhbmQgdGhhbmtzIHRvIFNoYXduIEVtZXJ5 IGZvcg0KPiBjb25kdWN0aW5nIHRoZSByZXZpZXcpLg0KPiANCj4gKiogSXMgdGhlcmUgYSByZWFz b24gd2h5IHRoZSBtZXRhLWRhdGEgaGVhZGVyIGluIHRoaXMgZG9jdW1lbnQgZG9lc27igJl0IG5v dGUNCj4gdGhpcyBhcyBhbiB1cGRhdGUgdG8gUkZDODc4MiAoZXNwZWNpYWxseSBzaW5jZSBpdCBp cyB1cGRhdGluZyBhbg0KPiBvcGVyYXRpb25hbA0KPiBnYXApPw0KDQpbTWVkXSBUaGlzIGlzIGJl Y2F1c2Ugd2UgZG9uJ3QgaGF2ZSBhbnkgdGV4dCBpbiBSRkM4NzgyIHRoYXQgd2UgYXJlIHVwZGF0 aW5nIG9yIG1vZGlmeWluZy4NCg0KVGhlIHVzZSBvZiAiRXh0ZW5kcy9FeHRlbmRlZCBieSIgZGVm aW5lZCBpbiBkcmFmdC1rdWVobGV3aW5kLXVwZGF0ZS10YWcgbWlnaHQgYmUgY29uc2lkZXJlZCBo ZXJlLCBidXQgd2UgZG9uJ3QgaGF2ZSB0aGVzZSB0YWdzIHlldC4gDQoNCj4gDQo+ICoqIE1pbm9y IGVkaXRvcmlhbCBuaXRzOg0KPiAtLSBTZWN0aW9uIDQuMS4gRWRpdG9yaWFsLiAgcy9Tb21lIHRp bWUvU29tZXRpbWUvDQo+IA0KDQpbTWVkXSBGaXhlZC4gDQoNCj4gLS0gU2VjdGlvbiA1LjEuIFJl Y29tbWVuZCBhZ2FpbnN0IGhhcmQtY29kaW5nIHRoZSBJQU5BIHJlZ2lzdHJ5IFVSTA0KPiANCj4g DQpbTWVkXSBPSywgZGVmaW5lZCBhIG5ldyByZWZlcmVuY2UgZW50cnkgdG8gcG9pbnQgdG8gdGhp cyBsaW5rLiBBbiB1cGRhdGVkIHZlcnNpb24gY2FuIGJlIHNlZW4gYXQ6DQpodHRwczovL2dpdGh1 Yi5jb20vYm91Y2FkYWlyL2ZpbHRlci1jb250cm9sL2Jsb2IvbWFzdGVyL2RyYWZ0LWlldGYtZG90 cy1zaWduYWwtZmlsdGVyLWNvbnRyb2wtMDYudHh0IA0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Jun 23 21:19:59 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E46B83A07BD; Tue, 23 Jun 2020 21:19:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-dots-signal-filter-control@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , Liang Xia , frank.xialiang@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159297239691.21127.4978875975256793804@ietfa.amsl.com> Date: Tue, 23 Jun 2020 21:19:56 -0700 Archived-At: Subject: [Dots] Erik Kline's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 04:19:57 -0000 Erik Kline has entered the following ballot position for draft-ietf-dots-signal-filter-control-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ questions ]] [ section 3.2.1 ] * "If not, the polling mechanism ... has to be followed". Should this use some actual 2119 language? * Is the specified client behaviour in the event of a 5.03 really MUST? That would definitely seem like recommended behaviour to me, but does it perhaps risk being over-specified to say retries without parameters MUST be attempted? I.e., should it be a SHOULD? [[ nits ]] [ section 6 ] * "entitled to access only to resources" -> "entitled to access only the resources" From nobody Tue Jun 23 22:01:15 2020 Return-Path: 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 F23B33A07E8; Tue, 23 Jun 2020 22:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net 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 13c0naH-9wit; Tue, 23 Jun 2020 22:01:08 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 B48D93A07EC; Tue, 23 Jun 2020 22:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7D3RMboudy+nO1MV6INXzPm/vNd1/fe0TEUMr9VUeFg=; b=MMeqXi/OebpXNS/kALb4kKf89a jVTpbe2sOP1YLbHNjQF2fY69IpMPn/cw+wTBqyi9C+ThukpTBWtQfNwPj2sr1h6WcsEocrnJnZ4Ci PtREUhP8mccX+t5pi/hjoLK4X/GQgpB3oXdPf8DWHx+tytO4Jk/oq/ku3A6bASYDjQi2IIKcRMDQJ rxBzywjpXdHKil1nmO0Iw/ZXWFKR08Mxcm6mW5lnY75axP4K1ZJ0acMIv6kaqohVG112XEPF77tPt ILc/NQeaxjce1SpWS5IqU7aPo8K5Y9Qoq+M+ruX3cmUghz77ROCXCwPjSH5vgsv6vLUHEMwXn8PG1 SZ3voVvA==; Received: from 95-27-147-103.broadband.corbina.ru ([95.27.147.103]:49266 helo=chichi) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jnxWy-0002nV-TJ; Wed, 24 Jun 2020 01:01:05 -0400 From: "Valery Smyslov" To: Cc: , References: <159198285186.17070.17617472622862856108@ietfa.amsl.com> <001d01d64142$186e5820$494b0860$@smyslov.net> <09c301d6486f$9e5b1f70$db115e50$@smyslov.net> In-Reply-To: <09c301d6486f$9e5b1f70$db115e50$@smyslov.net> Date: Wed, 24 Jun 2020 08:00:58 +0300 Message-ID: <004701d649e4$74ccd380$5e667a80$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQFCK0ctlS1o4W7dcWlYNoc1FzkNBgG7UWUfAdhCVXCp8tSgQA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2020-06-25 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 05:01:13 -0000 Hi, this is a reminder that the meeting will take place in about 24 hours. Presenters, please upload your slides to the datatracker or send them to the chairs before the meeting starts. Regards, Frank & Valery. > Hi, > > this is a reminder that DOTS WG is having a virtual interim meeting this > week on Thursday 25th June 2020 6:00-7:00 UTC. > Presenters, please upload your slides to the datatracker or send them to the > chairs before the meeting starts. > > > Meeting details: > > WebEx: > https://ietf.webex.com/ietf/j.php?MTID=m583b7d2e85e9bc229e902d12aa > bbaa41 > Jabber: xmpp:dots@jabber.ietf.org?join > Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-dots- > 01-dots?useMonospaceFont=true > Slides: https://datatracker.ietf.org/meeting/interim-2020-dots-01/session/dots > > > Agenda: > > 1. Note well, logistics and WG & individual drafts progress > - 10 min (Chairs) > 2. Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry > status update > (draft-ietf-dots-telemetry-08) > - 25 min (Med, Tiru) > 3. Multi-homing Deployment Considerations for Distributed-Denial-of- > Service Open Threat Signaling (DOTS) status update > (draft-ietf-dots-multihoming-04) > - 5 min (Med, Tiru) > 4. Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry > (draft-hayashi-dots-telemetry-use-cases-00) > - 5 min (Yuhei) > 5. A method for dots server deployment > (draft-chen-dots-server-hierarchical-deployment-02) > - 5 min (Meiling) > 6. Open Mic > - 5 min > 7. Wrapping up > - 5 min (Chairs) > > > More on WebEx participation: > > Meeting link: > https://ietf.webex.com/ietf/j.php?MTID=m583b7d2e85e9bc229e902d12aa > bbaa41 > Meeting number: 161 684 6922 > Password: WrMv7H2gBG2 > > More ways to join: > Join by video system: > Dial 1616846922@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > Join by phone: > 1-650-479-3208 Call-in number (US/Canada) > Access code: 161 684 6922 > > Regards, > Frank & Valery. From nobody Tue Jun 23 22:59:45 2020 Return-Path: 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 BCEAD3A0B93; Tue, 23 Jun 2020 22:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 CfUjAjFdF7jk; Tue, 23 Jun 2020 22:59:40 -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 595CE3A0B91; Tue, 23 Jun 2020 22:59:40 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 49sCCZ6QL4z5vZ0; Wed, 24 Jun 2020 07:59:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1592978378; bh=svgoZtvkKXYaBuYRX+lNI91H6OCwGWSc0FlDtz3fq5g=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=lonVCCWH85trL9WoB++1mI5xv+2pSC/7buB7OcCsU9LlOvrTINhlhqDRBpJvplmjY 1Cl6blic8YjhwUA2xdq1laVALuEi4VpiNEF8G7My589Sdrn8aKMdgEOruCA/MK+/i/ hwW34xpyxnkDpI4AXFRmldkRSmbHiwZJYrlCfL+d1AsL7lUnF8+Z39tRRd1S/pctQB N1kPEug16hfA0SReURzqLw5DqcrAJL1IAJew7sxHdMWoHGIAM2ElC8sPhBpcPuJ9hA UlnnIFGdS9Z3tfdlm7PrzLJvEyl3rgW4690oBiz1yGJquwCR9eb8kxK5ccZBlfXnDX piUfBe4dup3/A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 49sCCZ4tCTz8sY5; Wed, 24 Jun 2020 07:59:38 +0200 (CEST) From: To: Erik Kline , The IESG CC: "draft-ietf-dots-signal-filter-control@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov , Liang Xia Thread-Topic: Erik Kline's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) Thread-Index: AQHWSd66CD5XTTDI9EG2iimHNPE8AqjnNUsw Date: Wed, 24 Jun 2020 05:59:38 +0000 Message-ID: <13273_1592978378_5EF2EBCA_13273_290_1_787AE7BB302AE849A7480A190F8B9330314E6257@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159297239691.21127.4978875975256793804@ietfa.amsl.com> In-Reply-To: <159297239691.21127.4978875975256793804@ietfa.amsl.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Erik Kline's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 05:59:43 -0000 SGkgRXJpaywgDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiANCg0KUGxlYXNlIHNlZSBpbmxp bmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4g RGXCoDogRXJpayBLbGluZSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3Jn XQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDI0IGp1aW4gMjAyMCAwNjoyMA0KPiDDgMKgOiBUaGUg SUVTRw0KPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci1jb250cm9sQGlldGYu b3JnOyBkb3RzLWNoYWlyc0BpZXRmLm9yZzsNCj4gZG90c0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNs b3Y7IExpYW5nIFhpYTsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbQ0KPiBPYmpldMKgOiBFcmlr IEtsaW5lJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVyLWNv bnRyb2wtDQo+IDA2OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gRXJpayBLbGluZSBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1kb3RzLXNp Z25hbC1maWx0ZXItY29udHJvbC0wNjogTm8gT2JqZWN0aW9uDQo+IA0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFtbIHF1ZXN0aW9ucyBdXQ0KPiAN Cj4gWyBzZWN0aW9uIDMuMi4xIF0NCj4gDQo+ICogIklmIG5vdCwgdGhlIHBvbGxpbmcgbWVjaGFu aXNtIC4uLiBoYXMgdG8gYmUgZm9sbG93ZWQiLiAgU2hvdWxkIHRoaXMgdXNlDQo+IHNvbWUNCj4g ICBhY3R1YWwgMjExOSBsYW5ndWFnZT8NCg0KW01lZF0gV2UgaGF2ZSBhbHJlYWR5IGRpc2N1c3Nl ZCBpbiB0aGUgd2cgInMvaGFzIHRvL01VU1QiLiBUaGUgcmVhc29uIHdoeSB3ZSBhcmUgbm90IHVz aW5nIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaGVyZSBpcyB0aGF0IGl0IGlzIGZpbmUgZm9yIGEg ZG90cyBjbGllbnQgdG8gdXNlIGFueSBhbHRlcm5hdGl2ZSBtZXRob2QgKGluY2x1ZGluZyBmdXR1 cmUgb25lcykgdG8gZ2V0IHRoZSBzdGF0dXMgYXMgYSBiYWNrdXAgaWYgdGhlIHJlY29tbWVuZGVk IGJlaGF2aW9yIGlzIG5vdCBmb2xsb3dlZC4gICAgDQoNCj4gDQo+ICogSXMgdGhlIHNwZWNpZmll ZCBjbGllbnQgYmVoYXZpb3VyIGluIHRoZSBldmVudCBvZiBhIDUuMDMgcmVhbGx5IE1VU1Q/DQo+ IFRoYXQNCj4gICB3b3VsZCBkZWZpbml0ZWx5IHNlZW0gbGlrZSByZWNvbW1lbmRlZCBiZWhhdmlv dXIgdG8gbWUsIGJ1dCBkb2VzIGl0DQo+IHBlcmhhcHMNCj4gICByaXNrIGJlaW5nIG92ZXItc3Bl Y2lmaWVkIHRvIHNheSByZXRyaWVzIHdpdGhvdXQgcGFyYW1ldGVycyBNVVNUIGJlDQo+ICAgYXR0 ZW1wdGVkPyBJLmUuLCBzaG91bGQgaXQgYmUgYSBTSE9VTEQ/DQoNCltNZWRdIFBsZWFzZSBub3Rl IHRoYXQgIk1VU1QiIGFwcGxpZXMgZm9yICJpbml0aWFsIG1pdGlnYXRpb24gb3IgYSBtaXRpZ2F0 aW9uIHdpdGggYWRqdXN0ZWQgc2NvcGUiLiANCg0KICAgSWYgdGhlIERPVFMgY2xpZW50IHJlY2Vp dmVzIGEgNS4wMyAoU2VydmljZSBVbmF2YWlsYWJsZSkgd2l0aCBhDQogICBeXg0KICAgZGlhZ25v c3RpYyBwYXlsb2FkIGluZGljYXRpbmcgYSBmYWlsZWQgQUNMIHVwZGF0ZSBhcyBhIHJlc3BvbnNl IHRvIGFuDQogICBpbml0aWFsIG1pdGlnYXRpb24gb3IgYSBtaXRpZ2F0aW9uIHdpdGggYWRqdXN0 ZWQgc2NvcGUsIHRoZSBET1RTDQogICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl4NCiAgIGNsaWVudCBNVVNUIGltbWVkaWF0ZWx5IHNlbmQgYSBu ZXcgcmVxdWVzdCB3aGljaCByZXBlYXRzIGFsbCB0aGUNCiAgIHBhcmFtZXRlcnMgYXMgc2VudCBp biB0aGUgZmFpbGVkIG1pdGlnYXRpb24gcmVxdWVzdCBidXQgd2l0aG91dA0KICAgaW5jbHVkaW5n IHRoZSBBQ0wgYXR0cmlidXRlcy4NCg0KVGhpcyBiZWhhdmlvciBpcyBtZWFudCB0byBwbGFjZSB0 aGUgbWl0aWdhdGlvbiByZXF1ZXN0IHdpdGhvdXQgQUNMcyBzbyB0aGF0IGF0dGFjayBtaXRpZ2F0 aW9uIHN0YXJ0cyBpbW1lZGlhdGVseS4NCg0KPiANCj4gDQo+IFtbIG5pdHMgXV0NCj4gDQo+IFsg c2VjdGlvbiA2IF0NCj4gDQo+ICogImVudGl0bGVkIHRvIGFjY2VzcyBvbmx5IHRvIHJlc291cmNl cyIgLT4NCj4gICAiZW50aXRsZWQgdG8gYWNjZXNzIG9ubHkgdGhlIHJlc291cmNlcyINCj4gDQpb TWVkXSBGaXhlZC4gVGhhbmtzLiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Jun 24 02:45:21 2020 Return-Path: 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 27A8B3A0CF2 for ; Wed, 24 Jun 2020 02:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 ktFc0rYmMc_h for ; Wed, 24 Jun 2020 02:45:19 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 919343A0CF9 for ; Wed, 24 Jun 2020 02:45:17 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee15ef3209b9cc-53c27; Wed, 24 Jun 2020 17:44:59 +0800 (CST) X-RM-TRANSID: 2ee15ef3209b9cc-53c27 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[10.2.49.172]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35ef3209a4bf-2f3e0; Wed, 24 Jun 2020 17:44:59 +0800 (CST) X-RM-TRANSID: 2ee35ef3209a4bf-2f3e0 Date: Wed, 24 Jun 2020 17:44:58 +0800 From: "Meiling Chen" To: dots References: <159299144390.5943.7645084842093494073@ietfa.amsl.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.115[cn] Mime-Version: 1.0 Message-ID: <202006241744580031678@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart112576775405_=----" Archived-At: Subject: Re: [Dots] New Version Notification for draft-chen-dots-server-hierarchical-deployment-03.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 09:45:21 -0000 This is a multi-part message in MIME format. ------=_001_NextPart112576775405_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJICBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0LWNoZW4tZG90cy1zZXJ2ZXItaGll cmFyY2hpY2FsLWRlcGxveW1lbnQtMDMsDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1jaGVuLWRvdHMtc2VydmVyLWhpZXJhcmNoaWNhbC1kZXBsb3ltZW50LTAzDQoNCkNvbW1l bnRzLCBzdWdnZXN0aW9ucywgYW5kIHF1ZXN0aW9ucyBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuICAN Cg0KVGhhbmtzLA0KTWVpbGluZy4NCiANCkZyb206IGludGVybmV0LWRyYWZ0cw0KRGF0ZTogMjAy MC0wNi0yNCAxNzozNw0KVG86IExpIFN1OyBjaGVubWVpbGluZzsgTWVpbGluZyBDaGVuDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNoZW4tZG90cy1zZXJ2ZXIt aGllcmFyY2hpY2FsLWRlcGxveW1lbnQtMDMudHh0DQogDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtY2hlbi1kb3RzLXNlcnZlci1oaWVyYXJjaGljYWwtZGVwbG95bWVudC0wMy50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWVpbGluZyBDaGVuIGFuZCBwb3N0ZWQg dG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQogDQpOYW1lOiBkcmFmdC1jaGVuLWRvdHMtc2VydmVy LWhpZXJhcmNoaWNhbC1kZXBsb3ltZW50DQpSZXZpc2lvbjogMDMNClRpdGxlOiBBIG1ldGhvZCBm b3IgZG90cyBzZXJ2ZXIgZGVwbG95bWVudA0KRG9jdW1lbnQgZGF0ZTogMjAyMC0wNi0yNA0KR3Jv dXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEyDQpVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4tZG90cy1zZXJ2ZXIt aGllcmFyY2hpY2FsLWRlcGxveW1lbnQtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbi1kb3RzLXNlcnZlci1oaWVyYXJjaGlj YWwtZGVwbG95bWVudC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtY2hlbi1kb3RzLXNlcnZlci1oaWVyYXJjaGljYWwtZGVwbG95bWVudC0wMw0KSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt Y2hlbi1kb3RzLXNlcnZlci1oaWVyYXJjaGljYWwtZGVwbG95bWVudA0KRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jaGVuLWRvdHMtc2VydmVy LWhpZXJhcmNoaWNhbC1kZXBsb3ltZW50LTAzDQogDQpBYnN0cmFjdDoNCiAgIEFzIERPVFMgaXMg dXNlZCBmb3IgRERvUyBNaXRpZ2F0aW9uIHNpZ25hbGluZywgdGhlcmUgYXJlIGRpZmZlcmVudA0K ICAgZGVwbG95bWVudCBzY2VuYXJpb3MgZm9yIERPVFMgYWdlbnRzIGRlcGxveW1lbnQgZGVwZW5k aW5nIG9uIHRoZQ0KICAgbmV0d29yayB0b3BvbG9neS4gIFRoaXMgZG9jdW1lbnQgbWFkZSByZWNv bW1hbmRhdGlvbnMgZm9yIERPVFMgU2VydmVyDQogICBkZXBsb3ltZW50LCBpbmNsdWRlIElTUCBh bmQgZW50ZXJwcmlzZSBkZXBsb3ltZW50IHNjZW5hcmlvcy4gIFRoZQ0KICAgZ29hbCBpcyB0byBw cm92aWRlIHNvbWUgZ3VpZGFuY2UgZm9yIERPVFMgYWdlbnRzIGRlcGxveW1lbnQuDQogDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogDQogDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KIA0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCiANCiANCiANCg== ------=_001_NextPart112576775405_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
H= i all,

I  have updated = the draf= t-chen-dots-server-hierarchical-deployment-03,

https://tools.ietf.org/html/dra= ft-chen-dots-server-hierarchical-deployment-03

Comments, suggestions, and questions are more th= an welcome.  

Thanks,
Meiling.
=0A
&nbs= p;
Date: = 2020-06-24 17:37
Subject: New Version Notification for draft-che= n-dots-server-hierarchical-deployment-03.txt
&n= bsp;
=0A
A new version of I-D, draft-chen-dots-server-hierarchica= l-deployment-03.txt
=0A
has been successfully submitted by Meilin= g Chen and posted to the
=0A
IETF repository.
=0A
 =
=0A
Name: draft-chen-dots-server-hierarchical-deployment
= =0A
Revision: 03
=0A
Title: A method for dots server deploym= ent
=0A
Document date: 2020-06-24
=0A
Group: Individual= Submission
=0A
Pages: 12
=0A
URL:   &nb= sp;        https://www.ietf.org/interne= t-drafts/draft-chen-dots-server-hierarchical-deployment-03.txt
=0AStatus:         https://datatrac= ker.ietf.org/doc/draft-chen-dots-server-hierarchical-deployment/
=0A<= div>Htmlized:       https://tools.ietf.org/h= tml/draft-chen-dots-server-hierarchical-deployment-03=0A
Htmlize= d:       https://datatracker.ietf.org/doc/ht= ml/draft-chen-dots-server-hierarchical-deployment
=0A
Diff: =           https://www.ietf.or= g/rfcdiff?url2=3Ddraft-chen-dots-server-hierarchical-deployment-03
= =0A
 
=0A
Abstract:
=0A
   As DOTS is= used for DDoS Mitigation signaling, there are different
=0A
&nbs= p;  deployment scenarios for DOTS agents deployment depending on the<= /div>=0A
   network topology.  This document made recom= mandations for DOTS Server
=0A
   deployment, include I= SP and enterprise deployment scenarios.  The
=0A
  = ; goal is to provide some guidance for DOTS agents deployment.
=0A 
=0A
        &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;          
=0A=
 
=0A
 
=0A
Please note that it may take = a couple of minutes from the time of submission
=0A
until the htm= lized version and diff are available at tools.ietf.org.
=0A
 = ;
=0A
The IETF Secretariat
=0A
 
=0A
 = ;
=0A
 
=0A
------=_001_NextPart112576775405_=------ From nobody Wed Jun 24 09:26:27 2020 Return-Path: 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 11B1B3A1001; Wed, 24 Jun 2020 09:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 MoO27XuCBK4L; Wed, 24 Jun 2020 09:26:18 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 141093A0FE6; Wed, 24 Jun 2020 09:26:17 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05OGQ6fO040922; Wed, 24 Jun 2020 12:26:06 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 05OGQ6fO040922 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593015966; bh=Lf6k4Q/3a56kravNgjrfgf+LoBZe5esIgF0aeyfeoLk=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mQQ6SRHQyj5Imf9jUof/w+mJSIGuwCwnHxWMBK2rLXU1msvfij+V6zF9hLObXGuAy Nxk4/B1ZHdYxnYoGeYmPqla3ed4QwvpbAYBwJysJd1cWNzkHO0lmIGaQKM9W8KijXa cFx5CXxEi97xdmr/FCM5mUmO7BmZ3urbM2jnqEVA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05OGQ1Zs010895; Wed, 24 Jun 2020 12:26:01 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 24 Jun 2020 12:26:01 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 24 Jun 2020 12:26:01 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Wed, 24 Jun 2020 12:26:00 -0400 From: Roman Danyliw To: "mohamed.boucadair@orange.com" , The IESG CC: "dots-chairs@ietf.org" , Liang Xia , Valery Smyslov , "dots@ietf.org" , "draft-ietf-dots-signal-filter-control@ietf.org" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) Thread-Index: AQHWSOBfGrQmyujcAUWXkYWSxTpbEajl89wAgAAnZnA= Date: Wed, 24 Jun 2020 16:25:59 +0000 Message-ID: <20bf2fccf2334546becebc82ec4c79e9@cert.org> References: <159286314501.18862.4075221884152241102@ietfa.amsl.com> <10383_1592891036_5EF1969C_10383_179_8_787AE7BB302AE849A7480A190F8B9330314E56D2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <10383_1592891036_5EF1969C_10383_179_8_787AE7BB302AE849A7480A190F8B9330314E56D2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Roman Danyliw's No Objection on draft-ietf-dots-signal-filter-control-06: (with COMMENT) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 16:26:20 -0000 SGkgTWVkIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvdHMgPGRv dHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gU2VudDogVHVlc2RheSwgSnVuZSAyMywgMjAyMCAxOjQ0IEFNDQo+IFRvOiBS b21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4g Q2M6IGRvdHMtY2hhaXJzQGlldGYub3JnOyBMaWFuZyBYaWEgPGZyYW5rLnhpYWxpYW5nQGh1YXdl aS5jb20+OyBWYWxlcnkNCj4gU215c2xvdiA8dmFsZXJ5QHNteXNsb3YubmV0PjsgZG90c0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1maWx0ZXItDQo+IGNvbnRyb2xAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtEb3RzXSBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9uIG9uIGRy YWZ0LWlldGYtZG90cy1zaWduYWwtDQo+IGZpbHRlci1jb250cm9sLTA2OiAod2l0aCBDT01NRU5U KQ0KPiANCj4gSGkgUm9tYW4sDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQo+IA0K PiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiA+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6IFJvbWFuIERhbnlsaXcgdmlhIERhdGF0 cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10gRW52b3nDqcKgOg0KPiA+IGx1bmRpIDIy IGp1aW4gMjAyMCAyMzo1OSDDgMKgOiBUaGUgSUVTRyBDY8KgOg0KPiA+IGRyYWZ0LWlldGYtZG90 cy1zaWduYWwtZmlsdGVyLWNvbnRyb2xAaWV0Zi5vcmc7IGRvdHMtY2hhaXJzQGlldGYub3JnOw0K PiA+IGRvdHNAaWV0Zi5vcmc7IFZhbGVyeSBTbXlzbG92OyBMaWFuZyBYaWE7IGZyYW5rLnhpYWxp YW5nQGh1YXdlaS5jb20NCj4gPiBPYmpldMKgOiBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9u IG9uIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVyLQ0KPiA+IGNvbnRyb2wtMDY6ICh3aXRo IENPTU1FTlQpDQo+ID4NCj4gPiBSb21hbiBEYW55bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVy LWNvbnRyb2wtMDY6IE5vIE9iamVjdGlvbg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENP TU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gVGhhbmtzIGZvciByZXNwb25kaW5n IHRvIHRoZSBTRUNESVIgcmV2aWV3IChhbmQgdGhhbmtzIHRvIFNoYXduIEVtZXJ5DQo+ID4gZm9y IGNvbmR1Y3RpbmcgdGhlIHJldmlldykuDQo+ID4NCj4gPiAqKiBJcyB0aGVyZSBhIHJlYXNvbiB3 aHkgdGhlIG1ldGEtZGF0YSBoZWFkZXIgaW4gdGhpcyBkb2N1bWVudCBkb2VzbuKAmXQNCj4gPiBu b3RlIHRoaXMgYXMgYW4gdXBkYXRlIHRvIFJGQzg3ODIgKGVzcGVjaWFsbHkgc2luY2UgaXQgaXMg dXBkYXRpbmcgYW4NCj4gPiBvcGVyYXRpb25hbCBnYXApPw0KPiANCj4gW01lZF0gVGhpcyBpcyBi ZWNhdXNlIHdlIGRvbid0IGhhdmUgYW55IHRleHQgaW4gUkZDODc4MiB0aGF0IHdlIGFyZSB1cGRh dGluZw0KPiBvciBtb2RpZnlpbmcuDQo+IA0KPiBUaGUgdXNlIG9mICJFeHRlbmRzL0V4dGVuZGVk IGJ5IiBkZWZpbmVkIGluIGRyYWZ0LWt1ZWhsZXdpbmQtdXBkYXRlLXRhZw0KPiBtaWdodCBiZSBj b25zaWRlcmVkIGhlcmUsIGJ1dCB3ZSBkb24ndCBoYXZlIHRoZXNlIHRhZ3MgeWV0Lg0KDQpGYWly LiAgQ29uc2lkZXIgdGhlIG15IGNvbW1lbnQgcmVzb2x2ZWQuICBUaGFua3MhDQoNClJlZ2FyZHMs DQpSb21hbg0KDQo+ID4NCj4gPiAqKiBNaW5vciBlZGl0b3JpYWwgbml0czoNCj4gPiAtLSBTZWN0 aW9uIDQuMS4gRWRpdG9yaWFsLiAgcy9Tb21lIHRpbWUvU29tZXRpbWUvDQo+ID4NCj4gDQo+IFtN ZWRdIEZpeGVkLg0KPiANCj4gPiAtLSBTZWN0aW9uIDUuMS4gUmVjb21tZW5kIGFnYWluc3QgaGFy ZC1jb2RpbmcgdGhlIElBTkEgcmVnaXN0cnkgVVJMDQo+ID4NCj4gPg0KPiBbTWVkXSBPSywgZGVm aW5lZCBhIG5ldyByZWZlcmVuY2UgZW50cnkgdG8gcG9pbnQgdG8gdGhpcyBsaW5rLiBBbiB1cGRh dGVkDQo+IHZlcnNpb24gY2FuIGJlIHNlZW4gYXQ6DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9ib3Vj YWRhaXIvZmlsdGVyLWNvbnRyb2wvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC0N Cj4gZmlsdGVyLWNvbnRyb2wtMDYudHh0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UNCj4gY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl DQo+IHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPiBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlDQo+IHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkDQo+IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZA0KPiBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz DQo+IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4NCj4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxp bmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG90cw0K From nobody Wed Jun 24 12:30:23 2020 Return-Path: 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 64AD93A1142; Wed, 24 Jun 2020 12:30:21 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=cooperw.in header.b=SbeKFNPi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YVlewSK0 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 1pIa5ZKL4U4I; Wed, 24 Jun 2020 12:30:19 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A393C3A113A; Wed, 24 Jun 2020 12:30:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 040815C0060; Wed, 24 Jun 2020 15:30:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 24 Jun 2020 15:30:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=V gMpCm0UazPLMvncEyTnHdTN7gyQEQYLIjgkAb1L5XU=; b=SbeKFNPiVuJTYui8/ Xzn/zS+YNEkN/WBb1cM9/XHITvYdgoMHUYerS0eURqQ1glQvQZJlI/4Wwj0T+InY 6U/1Asopm8mVLPvNgCls2Ru1qucjJgBybINuN9WZ8qJVY5eAtRNqE6fJ2Pt2TDB1 9v6lTUhK5+asA8MAlUfixSmu4Aep901sDtWB4vTZ8VrHbyYwkv5KMRapRW8DJ3Ii 5+3tstAJ04X4FpqPKqrS+voYxQC+UFBo5yN9caTZPEPwBERYZhJ4jOrlQRr1kMUv 8/J34nI7+oS8CInNwV/qLZTuQjTIpMCn0up8Uu/U130gye/eDE/Fu0fiz9S6YzSh am+tQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=VgMpCm0UazPLMvncEyTnHdTN7gyQEQYLIjgkAb1L5 XU=; b=YVlewSK0Wq5pzhzlzHhEgROQqNOGPU8Q5j+RKsSSlGzCp0mIBVaUE+LEs 4sQeuxJURSRfx6j8dsQNHbsfzkb+DIkfC+S5qiTwuZ2J7sWSHLi9RViveRrtZLy6 LiniBFLkv8SPpZ8GXCFJTvJkE47e7D9SshZW6KaFy0z2xQDQ/1jf9tvryIHsM0Bn aoLeKUmVBC/yACDbsaug3Edwv+bt/b7j2IxbzpE2xdoHhjNZQdsIcO7eZ0AphVNN v66J15NUIvnOoRW72pURRvYFg5UqEW5W9EuQ3Y1MVfVmge4lQuA8bhxArTMdi0se CAlQeIHa0YQRTyRtiq0+xGEcj1JYA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgudeffecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrges tghoohhpvghrfidrihhnqeenucggtffrrghtthgvrhhnpeeljeevkeekfeegjeekueejle duueefveekvdeuhefffefhudeggefhffehudfhtdenucffohhmrghinhepfhhirhgvvgih vgdrtghomhdpghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucfkphepudejfedrfe ekrdduudejrdejfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 4ECC73280063; Wed, 24 Jun 2020 15:30:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: Date: Wed, 24 Jun 2020 15:30:15 -0400 Cc: "gen-art@ietf.org" , "last-call@ietf.org" , "draft-ietf-dots-signal-filter-control.all@ietf.org" , "dots@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55D35C24-293F-4F78-AD18-0342ED752ABB@cooperw.in> References: <159143563395.23234.11119777689885195262@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330314D96A7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: Christer Holmberg , "mohamed.boucadair@orange.com" X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Dots] [Gen-art] Genart last call review of draft-ietf-dots-signal-filter-control-04 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 19:30:21 -0000 Christer, thanks for your review. Med, thanks for addressing his = comments. I entered a No Objection ballot. Alissa > On Jun 8, 2020, at 1:42 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> Thank you for the review.=20 >>=20 >> OK with all your suggestions.=20 >=20 > Thank You! :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > FWIW, you can track the changes to address your review at: = https://protect2.fireeye.com/v1/url?k=3Ddb0f6041-85afa3e8-db0f20da-86959e4= 72243-5faeb82b3c90bf51&q=3D1&e=3Df43c50b7-ac0b-4eba-bc4b-55c0e7f8a2b9&u=3D= https%3A%2F%2Fgithub.com%2Fboucadair%2Ffilter-control%2Fblob%2Fmaster%2FCh= rister's%20Review.pdf=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Christer Holmberg via Datatracker [mailto:noreply@ietf.org]=20 >> Envoy=C3=A9 : samedi 6 juin 2020 11:27 =C3=80 : gen-art@ietf.org Cc :=20= >> draft-ietf-dots-signal-filter-control.all@ietf.org; last-=20 >> call@ietf.org; dots@ietf.org Objet : Genart last call review of=20 >> draft-ietf-dots-signal-filter- >> control-04 >>=20 >> Reviewer: Christer Holmberg >> Review result: Ready with Nits >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area=20= >> Review Team (Gen-ART) reviews all IETF documents being processed by=20= >> the IESG for the IETF Chair. Please treat these comments just like=20= >> any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-dots-signal-filter-control-04 >> Reviewer: Christer Holmberg >> Review Date: 2020-06-06 >> IETF LC End Date: 2020-06-15 >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: The document is well written, and pretty much ready for=20 >> publication. I do have a couple of minor editorial comments that I'd=20= >> like the authors to address. >>=20 >> Major issues: None >>=20 >> Minor issues: None >>=20 >> Nits/editorial comments: >>=20 >> Q1: Please expand DOTS on first occurence. >>=20 >> --- >>=20 >> Q2: The Security Considerations say: >>=20 >> "This specification does not allow to create new filtering rules, >> which is the responsibility of the DOTS data channel." >>=20 >> Unless I missed it, I think it would be useful to state this also=20 >> earlier in the document, e.g., in the Introduction. >>=20 >> --- >>=20 >> Q3: The Security Consideration say: >>=20 >> "The security considerations discussed in >> [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel]=20 >> need >> to be taken into account." >>=20 >> I think it is obvious that those security considerations need to be=20= >> taken into account. I would suggest to re-phrase, and say something=20= >> like: >>=20 >> "The generic security considerations for DOTS signal channels are >> defined in [I-D.ietf-dots-signal-channel]. The generic security >> considerations for DOTS data channels are defined in >> [I-D.ietf-dots-data-channel]. This Section defines the security >> considerations that are specific to the DOTS extension defined >> in this document." >>=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Jun 25 03:18:19 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676BB3A08F0; Thu, 25 Jun 2020 03:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dots-signal-filter-control@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , Liang Xia , frank.xialiang@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159308029339.7079.13156081128012772649@ietfa.amsl.com> Date: Thu, 25 Jun 2020 03:18:13 -0700 Archived-At: Subject: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-filter-control-06=3A_=28with_COMMENT=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 10:18:14 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dots-signal-filter-control-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I appreciated the clarity, the use of IPv6 examples, and the inclusion of the YANG model. Only one minor suggestion about the title of section 1.2 as "The Solution" looks a little marketing ;-) I would prefer "Mitigation Technique" or something more 'engineering-oriented' Regards -éric From nobody Thu Jun 25 03:31:12 2020 Return-Path: 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 BD7D53A090A; Thu, 25 Jun 2020 03:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 CJsqzMmpq10j; Thu, 25 Jun 2020 03:31:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7D43A0598; Thu, 25 Jun 2020 03:31:05 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 49sxBH679nz5vYj; Thu, 25 Jun 2020 12:31:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593081063; bh=i8cMP3Wp0Ni4/tdYdJYTFr+IKRMSND2M9z2colBnyqY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gu9UZTeH1moCVihQlFlQR58PbU6exOqziNN/obVgjCcnaNElREO2hDQyskXmyzO0a IScc/7xdBOjxiyx5a5uRac352q6Bzv6haNDB3MbMDunuUXo/tw8gN2enp3Q1xWja9z rXH7h5TVidxPLNH2Ib/t6bw/gmxivlAPAq2ENp03De7J2bAt/9fhKhyJ0vjV2oco9M wlSJrrfYe05Io/LU3OyX+/t8aeKIDlmAawQPYrvjfyCURZ0acmkoPPL7AQbC6jLV1G jeaDaJwcoIExl0r8cZ/sy8oPQltdEVo1Z9+knRUwNZL7ejDn1Hltgx6IqEi/3wAZEs sn8bHB6ykDoBw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 49sxBH4Bfmz3wbJ; Thu, 25 Jun 2020 12:31:03 +0200 (CEST) From: To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-dots-signal-filter-control@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov , Liang Xia Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-signal-filter-control-06:_(with_COMMENT)?= Thread-Index: AQHWStnxmJ9uQEIm8U2BE2gq3ckiwqjpIGog Date: Thu, 25 Jun 2020 10:31:03 +0000 Message-ID: <4843_1593081063_5EF47CE7_4843_485_1_787AE7BB302AE849A7480A190F8B9330314E6F80@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159308029339.7079.13156081128012772649@ietfa.amsl.com> In-Reply-To: <159308029339.7079.13156081128012772649@ietfa.amsl.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-filter-control-06=3A_=28with_COMMENT=29?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 10:31:07 -0000 SGkgRXJpYywgDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gDQoNClBsZWFzZSBzZWUgaW5saW5l LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERl wqA6IMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3Jn XQ0KPiBFbnZvecOpwqA6IGpldWRpIDI1IGp1aW4gMjAyMCAxMjoxOA0KPiDDgMKgOiBUaGUgSUVT Rw0KPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci1jb250cm9sQGlldGYub3Jn OyBkb3RzLWNoYWlyc0BpZXRmLm9yZzsNCj4gZG90c0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNsb3Y7 IExpYW5nIFhpYTsgZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbQ0KPiBPYmpldMKgOiDDiXJpYyBW eW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1maWx0ZXItDQo+ IGNvbnRyb2wtMDY6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBD T01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1 dCBpbnRvIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBJIGFwcHJlY2lhdGVkIHRoZSBjbGFyaXR5LCB0 aGUgdXNlIG9mIElQdjYgZXhhbXBsZXMsIGFuZCB0aGUgaW5jbHVzaW9uIG9mDQo+IHRoZQ0KPiBZ QU5HIG1vZGVsLg0KPiANCj4gT25seSBvbmUgbWlub3Igc3VnZ2VzdGlvbiBhYm91dCB0aGUgdGl0 bGUgb2Ygc2VjdGlvbiAxLjIgYXMgIlRoZSBTb2x1dGlvbiINCj4gbG9va3MgYSBsaXR0bGUgbWFy a2V0aW5nIDstKQ0KDQpbTWVkXSBUaGF04oCZcyBub3QgdGhlIGludGVudCA6LSkgVGhpcyB3YXMg dnMuICJUaGUgUHJvYmxlbSIgaW4gU2VjIDEuMSAgDQoNCiBJIHdvdWxkIHByZWZlciAiTWl0aWdh dGlvbiBUZWNobmlxdWUiIG9yDQo+IHNvbWV0aGluZw0KPiBtb3JlICdlbmdpbmVlcmluZy1vcmll bnRlZCcNCj4gDQoNCltNZWRdIEhhcHBpbHkuIENoYW5nZWQgdG8gIkNvbnRyb2xsaW5nIEZpbHRl cmluZyBSdWxlcyBVc2luZyBET1RTIFNpZ25hbCBDaGFubmVsIi4gDQoNCj4gUmVnYXJkcw0KPiAN Cj4gLcOpcmljDQo+IA0KPiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu Jun 25 04:28:16 2020 Return-Path: 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 149C53A0949; Thu, 25 Jun 2020 04:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ShA1q6eu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=K2GCEEaK 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 gmvTt8fdx_RN; Thu, 25 Jun 2020 04:28:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234783A0948; Thu, 25 Jun 2020 04:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4212; q=dns/txt; s=iport; t=1593084492; x=1594294092; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7tdZCoQVGpO7ydRVwiHwPdd8KETJj6IVHIeu7Lp4co8=; b=ShA1q6euItn892x4dMnI2feqlz0Wi5iKGRQFLyIq/CEYbab1CgQ6I24S F24K7++shBK1jCaiUPWjifBjWS/yyc+a0Alw8s1SFJBrPXQiz+D2XGzmv VyHSCRp9gTyWqlGB5nSoo6jnOU67jZ4guQkxO8DKh0u4tq1R3qS9zxqtB Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A6NxHMRZa/WgCALkzpHf9kiv/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD4LB4vRLhqzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutYEfbpHK/qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsAQDHiPRe/4QNJK1lGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFSUQeBRy8shCSDRgONR5hXgUKBEANVCwEBAQw?= =?us-ascii?q?BAS0CBAEBhEcCF4IHAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFcgEBAQMBEhE?= =?us-ascii?q?RDAEBLQoBCwQCAQgRAwECAwIjAwICAjAUAQUDCAIEAQ0FGweDBIJMAw4gAad?= =?us-ascii?q?mAoE5iGF2gTKDAQEBBYUhGIIOCYEOKoJnhWCEHRqBQT+BESccgk0+hAgBEgE?= =?us-ascii?q?hgxQzgi2PBByCVTyiPQqCW5RKhGgDHYJxiSWSbYQbjSKeTAIEAgQFAg4BAQW?= =?us-ascii?q?BaiJmcHAVGksBgj5QFwINjh43gzqKVnQ3AgYBBwEBAwkBe5BXAQE?= X-IronPort-AV: E=Sophos;i="5.75,279,1589241600"; d="scan'208";a="779930955" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2020 11:28:10 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 05PBSAUZ000726 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Jun 2020 11:28:10 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 25 Jun 2020 06:28:10 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 25 Jun 2020 06:28:10 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 25 Jun 2020 07:28:10 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DQku1hc/q6KlCvXlciO1eXtG98i+dxEPXisswJiclW5klLSk/ZtrYfngAsov2m5S7YxQ/3dedMmtgteNypeGfQgqvsSmaDpWhlLhhwuYnBOfr8iaBzeYufdd/+0tzO29m6IIZvgmSYEBzKUMr6n8fF2AOZzkAypUltI6Q9mL3D1iA1JNGrUAPO6V7b609y24ScJpeB0xhksPLCUw+rkGbQvctTEcMJcL73iL+gf7XtGZ8jA8K/VfXCrtwK1lbK3ldphCdJs2kE3mMa8CQRd/p+nSV28XGnXwtZ32hclDq0WMM4N9+bJccN+aBU1VUk8QQK4/cvz2xCl74rysu8VTVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7tdZCoQVGpO7ydRVwiHwPdd8KETJj6IVHIeu7Lp4co8=; b=ZbbXmfw89aK6fRXUhOHFARl7soPiN4JKp9iNINT56BfpaE28NfSdVVAK7aiGs5OoX9knkTrC+Hgnn2l6QKNwLLHd8t/EeMmVX7YtuPRaGedLblr8jTKzAep41UJ0c5aLQBAtgsX3nLbJVaBU9BaB1ntbizm9kUntwyUaRSDIRgJdmeTnKPifkRI9LJT9c8rk9jWajsKeV4h9itQJ+qMc/ikPZrIW8FEOnRmdHH4ANP3xkR9qCbYJjphV56xx2ywbv3L0vMk5XOgU9LLLvD38QhV4wpewy/SYdE6gC8yVHSzv+MewSrfMvm11Wd+07Epc2kFpLjXWJR+7XbJqgZ4eRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7tdZCoQVGpO7ydRVwiHwPdd8KETJj6IVHIeu7Lp4co8=; b=K2GCEEaKpNqHK5S89ugwpVyCFSbgkGF+IySBgwNcXYzgn3XiY1PH5gzaTAvRa3uqYgNCbS2WHZ7AdWItDjNCmxhnfsevFXBvnFzVQIDve1VP9WNML2MRXPOZA3lXNOHCb6Cu9TTj+DKgQX9pLNDfNHua9rhVtm4Nty55vY9mEzE= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM6PR11MB3899.namprd11.prod.outlook.com (2603:10b6:5:19c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Thu, 25 Jun 2020 11:28:09 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3131.021; Thu, 25 Jun 2020 11:28:09 +0000 From: "Eric Vyncke (evyncke)" To: "mohamed.boucadair@orange.com" , The IESG CC: "draft-ietf-dots-signal-filter-control@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov , Liang Xia Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-signal-filter-control-06:_(with_COMMENT)?= Thread-Index: AQHWStnxmJ9uQEIm8U2BE2gq3ckiwqjpIGoggAAyzwA= Date: Thu, 25 Jun 2020 11:28:09 +0000 Message-ID: <83D92194-3D05-40A6-983A-3DAFF7626553@cisco.com> References: <159308029339.7079.13156081128012772649@ietfa.amsl.com> <4843_1593081063_5EF47CE7_4843_485_1_787AE7BB302AE849A7480A190F8B9330314E6F80@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <4843_1593081063_5EF47CE7_4843_485_1_787AE7BB302AE849A7480A190F8B9330314E6F80@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:80a1:2113:c9dd:141d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 948a586b-f33c-41f0-79e6-08d818fad686 x-ms-traffictypediagnostic: DM6PR11MB3899: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0445A82F82 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ih64BSCgkEAqZqWy07aouPhhKVrPxPzAKbnz/1kiswfqtn4CZCvNM1wSseWJ4EwiYqe6kUPD+R0wVww/zL/2w1Wl18qZ/H/fA8E2pGHQKkXohpmRZ4Vd9w96Yzd2ZeUJ+EOKOH/WpG3HNKfrr29FLe8E1ajb52eeG+2CJuQjA53wH4Vy63qANYyPD6qB6ZfT0ncdtIsM1yN11s6SKZC3ePvBR+GYb5jBh9YxWz205l+Hjvk1SAYnbEM0Nhq6ahDj79q9XA9WnphAIzLvt2LpQDkGNyqqNUjiqv4fMRQD45yPUS95hD53iLjOKixYWrLRUc9ZB85kIC+8KDuP5ATlbg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(366004)(136003)(396003)(6506007)(86362001)(6486002)(316002)(76116006)(66476007)(5660300002)(66446008)(66556008)(66946007)(478600001)(110136005)(91956017)(54906003)(2616005)(6512007)(53546011)(64756008)(83380400001)(4326008)(2906002)(71200400001)(186003)(8936002)(224303003)(33656002)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: M44z1yKA/OYUze6H1yUh9yU/saujNPbaUPQBLI8Zj/4rODDmD4XE+M53xBT/ryz4lYEAlqG5VYyOTUO90/pTrMeGm3hbEim1lkNU6MCGfntj25qjjSR8al+gIC0xHXEreMvlAP/R0Gz3HHmQf4fffJ36iPfXp9LEmOZdALXJ5l9wCXy+BYhm4vPYFMmz4J4q6NT+UWZw8uzlxOj8Xt+YvxJUrqINwe8lhfvyeh+YoNGBZmSYzTkflLueSLuAS0O+jCt5/KwxaRMjGssSGTAsNMrwmit1onmvqoJOf5vypkzz2SKsF17Jl4d7pJpAOdbgCw+krrv5JImkNS24bKMj0YDrPsiATXHWTtcqeM0wHpOSpAblZyzJvituaJXUHBrWDvRVEWGoeUx69tbrKU76ab7Vto0M+PUFFGrUSkeXcqYafNSmbxjK9Do0aPLlKFk9q/TLrK7jXvk1/WS7aKohIpt1EQpe+Ljn6G5LXQpT4cR3eiSTeK9k0GewxJkuA8VaT2143eUWVBPPZId8R0CXSaqvPz7yWcTC3SdU1nKuZ90= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB1753.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 948a586b-f33c-41f0-79e6-08d818fad686 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2020 11:28:09.1263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /c8yh//HgZeRD7tjFY21EcVG8FdpziYlZvidyQShTrxDgYU+yzs4utqEYkQWS0Q9D7obIuEYInm/TxaXKFCt+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3899 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-filter-control-06=3A_=28with_COMMENT=29?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 11:28:14 -0000 TWVkDQoNClNvdW5kcyBnb29kIHRvIG1lIChhbmQgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIG1hcmtl dGluZyB0d2lzdCB3YXMgbm90IG9uIHB1cnBvc2UpDQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KRGF0ZTogVGh1cnNkYXksIDI1IEp1bmUgMjAy MCBhdCAxMjozMQ0KVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4sIFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KQ2M6ICJkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci1jb250 cm9sQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1maWx0ZXItY29udHJvbEBpZXRm Lm9yZz4sICJkb3RzLWNoYWlyc0BpZXRmLm9yZyIgPGRvdHMtY2hhaXJzQGlldGYub3JnPiwgImRv dHNAaWV0Zi5vcmciIDxkb3RzQGlldGYub3JnPiwgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlz bG92Lm5ldD4sIExpYW5nIFhpYSA8ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbT4NClN1YmplY3Q6 IFJFOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1kb3RzLXNpZ25h bC1maWx0ZXItY29udHJvbC0wNjogKHdpdGggQ09NTUVOVCkNCg0KICAgIEhpIEVyaWMsIA0KDQog ICAgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiANCg0KICAgIFBsZWFzZSBzZWUgaW5saW5lLiANCg0K ICAgIENoZWVycywNCiAgICBNZWQNCg0KICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQogICAgPiBEZSA6IMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5 QGlldGYub3JnXQ0KICAgID4gRW52b3nDqSA6IGpldWRpIDI1IGp1aW4gMjAyMCAxMjoxOA0KICAg ID4gw4AgOiBUaGUgSUVTRw0KICAgID4gQ2MgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRl ci1jb250cm9sQGlldGYub3JnOyBkb3RzLWNoYWlyc0BpZXRmLm9yZzsNCiAgICA+IGRvdHNAaWV0 Zi5vcmc7IFZhbGVyeSBTbXlzbG92OyBMaWFuZyBYaWE7IGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5j b20NCiAgICA+IE9iamV0IDogw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll dGYtZG90cy1zaWduYWwtZmlsdGVyLQ0KICAgID4gY29udHJvbC0wNjogKHdpdGggQ09NTUVOVCkN CiAgICA+IA0KICAgID4gDQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBDT01NRU5UOg0KICAg ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gDQogICAgPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1 dCBpbnRvIHRoaXMgZG9jdW1lbnQuDQogICAgPiANCiAgICA+IEkgYXBwcmVjaWF0ZWQgdGhlIGNs YXJpdHksIHRoZSB1c2Ugb2YgSVB2NiBleGFtcGxlcywgYW5kIHRoZSBpbmNsdXNpb24gb2YNCiAg ICA+IHRoZQ0KICAgID4gWUFORyBtb2RlbC4NCiAgICA+IA0KICAgID4gT25seSBvbmUgbWlub3Ig c3VnZ2VzdGlvbiBhYm91dCB0aGUgdGl0bGUgb2Ygc2VjdGlvbiAxLjIgYXMgIlRoZSBTb2x1dGlv biINCiAgICA+IGxvb2tzIGEgbGl0dGxlIG1hcmtldGluZyA7LSkNCg0KICAgIFtNZWRdIFRoYXTi gJlzIG5vdCB0aGUgaW50ZW50IDotKSBUaGlzIHdhcyB2cy4gIlRoZSBQcm9ibGVtIiBpbiBTZWMg MS4xICANCg0KICAgICBJIHdvdWxkIHByZWZlciAiTWl0aWdhdGlvbiBUZWNobmlxdWUiIG9yDQog ICAgPiBzb21ldGhpbmcNCiAgICA+IG1vcmUgJ2VuZ2luZWVyaW5nLW9yaWVudGVkJw0KICAgID4g DQoNCiAgICBbTWVkXSBIYXBwaWx5LiBDaGFuZ2VkIHRvICJDb250cm9sbGluZyBGaWx0ZXJpbmcg UnVsZXMgVXNpbmcgRE9UUyBTaWduYWwgQ2hhbm5lbCIuIA0KDQogICAgPiBSZWdhcmRzDQogICAg PiANCiAgICA+IC3DqXJpYw0KICAgID4gDQogICAgPiANCg0KDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICAg Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jDQogICAgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCiAgICBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KICAgIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4NCg0KICAgIFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7DQogICAgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQogICAgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQogICAgQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KICAgIFRoYW5rIHlvdS4NCg0KDQo= From nobody Thu Jun 25 08:02:22 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4C13A0C02; Thu, 25 Jun 2020 08:02:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <159309734123.18419.7896905555702935707@ietfa.amsl.com> Date: Thu, 25 Jun 2020 08:02:21 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 15:02:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Kaname Nishizuka Mohamed Boucadair Tirumaleswar Reddy Takahiko Nagata Filename : draft-ietf-dots-signal-filter-control-07.txt Pages : 26 Date : 2020-06-25 Abstract: This document specifies an extension to the Distributed Denial-of- Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de- activate existing filtering rules during a DDoS attack. The characterization of these filtering rules is conveyed by a DOTS client during an idle time (i.e., no mitigation is active) by means of the DOTS data channel protocol. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Controlling Filtering Rules Using Distributed Denial- of-Service Open Threat Signaling (DOTS) Signal Channel"; o reference: RFC XXXX o [RFCXXXX] Please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter-control-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-filter-control-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 25 12:29:15 2020 Return-Path: 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 92F553A0FE8 for ; Thu, 25 Jun 2020 12:29:13 -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 58YMOfAF5FBe for ; Thu, 25 Jun 2020 12:29:12 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29103A0C5A for ; Thu, 25 Jun 2020 12:29:11 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 49t97B3jc6z4wYW; Thu, 25 Jun 2020 21:29:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593113350; bh=+fpcJ6E1zBKrGNKRFqxDUZdGvNCoqeXW4c/K4Zeqg3U=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=aoEHgLE8TkqSgfiafe8g1+X+Mdyd1dHPNG36V28pAumtsu51kyA2AjDfblhbXJKPr 88cVUxbYlolp0sLvYb4ZzzyiY8c511iQIchzFVlxqP2cIGeW9XvktVEQiIXh/HU2JW ULzouswQVlmm6/DqoYJER6hjUd7j0PQWwZKJhwYHChisRbjAFoEp+kjQ44w7oY8EAl msEsUrFSjHg/qM4Nknk5CZxrWP25vE6fhUXfEKkhhLQNatKo8I+eW6QtXuRrTGAu+Q Ejd9Fuq04mX+c+zTZig0FJ1b8NHT2UqbruBj7qH5DHhwkXVKqdtnij6SPBSdf3CvP5 noAIU8xmfl9Bw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 49t97B2z5qzDq7t; Thu, 25 Jun 2020 21:29:10 +0200 (CEST) From: To: kaname nishizuka CC: "dots@ietf.org" Thread-Topic: DOTS Telemetry: Interop Clarification #1 Thread-Index: AdZLJuT9wboSGkyjRCO9gphmXHj4nw== Date: Thu, 25 Jun 2020 19:29:09 +0000 Message-ID: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@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.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314E762DOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 19:29:14 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E762DOPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kaname, We discussed this issue in the interim: =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the client= or created by the server. -Those are totally different resources. For example, Uri-Query won't be applicable to the telemetry resources poste= d by the client. =3D=3D Can you please identify precisely which parts of the text need to be update= d? Thank you Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E762DOPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kaname,

 

= We discussed this issue in the interim:

=  

= =3D=3D

= Current Uri-Path can't distinguish telemetry resources posted by the client= or created by the server.

= –Those are totally different resources.

= For example, Uri-Query won't be applicable to the telemetry resources poste= d by the client.

= =3D=3D

=  

= Can you please identify precisely which parts of the text need to be update= d?

=  

= Thank you

=  

= Cheers,

= Med

=  

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E762DOPEXCAUBMA2corp_-- From nobody Thu Jun 25 12:31:39 2020 Return-Path: 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 2978C3A0FE8 for ; Thu, 25 Jun 2020 12:31:38 -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 FCwKu7MTEKT2 for ; Thu, 25 Jun 2020 12:31:36 -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 224A83A0FE7 for ; Thu, 25 Jun 2020 12:31:36 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 49t99y3gGzzFq15; Thu, 25 Jun 2020 21:31:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593113494; bh=Cj89lTnlGtjuvn1BqZZuI+o//D+22HGKWHbL8V7GX6Q=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=dIEGbVNZS7aQ1GlmuHf0u8hHR19GagsO4WcXbfAO3Vd7aYy4TPRfZxzT1mKM2+Dqu URyq7myeRTyZMFFLDhd17W4Xa7u2LwLWMYimgsldR2dFgY5ZqODLPykcGu9r6W+w9U yxo90IDlvyHavuQeeqIxmbp3QgcTCGpO4NDET6YqzFKppCbeASDDhEaAczj/QiWHWS W9WAsy81XPZK0dcCPSkdtE5aGimuWsMRbOTAzTNg0MNjozjRmEePc88doJxAi9KZTk IbTGdD68JI2XCfmiD9yNRrqvFmsmvtJtRzLuJU7vExGYRMPP9SkMz2LoFxRrpSAwSu A2XnAUmJDJM1g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 49t99y2lvfzCqkV; Thu, 25 Jun 2020 21:31:34 +0200 (CEST) From: To: kaname nishizuka CC: "dots@ietf.org" Thread-Topic: DOTS Telemetry: Interop Clarification #3 Thread-Index: AdZLJzstzanwENMBRvG6m9wslEq8bA== Date: Thu, 25 Jun 2020 19:31:33 +0000 Message-ID: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@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.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314E7645OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 19:31:38 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E7645OPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, You reported the following in the interim : =3D=3D 3."DOTS agents MUST NOT include 'attack-name' attribute except if the corre= sponding attack mapping details were not shared with the peer DOTS agent". = But how can the DOTS server know they're shared or not? =3D=3D=3D This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else? Thanks. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E7645OPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re-,

 

= You reported the following in the interim :

=3D=3D

= 3."DOTS agents MUST NOT include 'attack-name' attribute except if the = corresponding attack mapping details were not shared with the peer DOTS age= nt". But how can the DOTS server know they're shared or not?

= =3D=3D=3D

=  

= This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else?

=  

= Thanks.

=  

= Cheers,

= Med

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E7645OPEXCAUBMA2corp_-- From nobody Thu Jun 25 18:51:08 2020 Return-Path: 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 AC5853A10E0 for ; Thu, 25 Jun 2020 18:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nttv6.jp 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 eQAgVhSToUhf for ; Thu, 25 Jun 2020 18:51:02 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id C99DB3A10DF for ; Thu, 25 Jun 2020 18:51:01 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id A759B25F6BB; Fri, 26 Jun 2020 10:50:59 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1593136259; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mSAtOmtpbh1syrpupH+EYSELxb4MKF4BCtXdr7cEsp8=; b=YHPAILymdNtr5feIvuDO5h2yo0UPaiqq1W/KdudArzGrqJdY/aNDVtdRg2jNwCkF8Hu4A/ C/O0oI3ptIb4YDUwXcmFeN3mxG+fzgruW0tIdH6ncERRN2qwQdyUFJTNeK0cRRRRlUfDGZ LmTnQsZhqYbiAQloTp5beDTwFbusLeY= Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 81F6D75900F; Fri, 26 Jun 2020 10:50:59 +0900 (JST) To: mohamed.boucadair@orange.com Cc: "dots@ietf.org" References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: Date: Fri, 26 Jun 2020 10:50:59 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------D8E0FFD65E1C62FE71100757" Content-Language: en-US Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 01:51:07 -0000 This is a multi-part message in MIME format. --------------D8E0FFD65E1C62FE71100757 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Med, Yes, it's implementation-specific. I didn't intend to suggest a text here, but wanted to hear ideas on how others might handle it. regards, kaname On 2020/06/26 4:31, mohamed.boucadair@orange.com wrote: > > 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. --------------D8E0FFD65E1C62FE71100757 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Med,


Yes, it's implementation-specific.
I didn't intend to suggest a text here, but wanted to hear ideas on how others might handle it.

regards,
kaname

On 2020/06/26 4:31, mohamed.boucadair@orange.com wrote:

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.

--------------D8E0FFD65E1C62FE71100757-- From nobody Thu Jun 25 22:15:14 2020 Return-Path: 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 592C23A1116 for ; Thu, 25 Jun 2020 22:15:12 -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, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 hT0r1P_-8-tZ for ; Thu, 25 Jun 2020 22:15:10 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DEF33A00D2 for ; Thu, 25 Jun 2020 22:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1593148509; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sRcDjUXA4LSSYlHBa8A4aa/SYXIZfKyueVhJPRggFds=; b=ChBnrp1dun5sqS6PBqJbWmW8w5vNNRaZlTM0CqSCcm9UqN4xc3D8Afgy+EyHkMAM1cPt7e kfElCJ+G2xTGdAnVD9XFZd1XN5cdAweYiW6NoDVsQuWM2oIzMplrYYtvLvi1qv9WXNpe6d /Y7YE9aPjonxlagMPI+qidN/P6z555c= Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-416-dM_uycXwNee2LCa73BJ_SA-1; Fri, 26 Jun 2020 01:15:07 -0400 X-MC-Unique: dM_uycXwNee2LCa73BJ_SA-1 Received: from SA0PR16MB3838.namprd16.prod.outlook.com (2603:10b6:806:86::9) by SA0PR16MB3920.namprd16.prod.outlook.com (2603:10b6:806:86::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Fri, 26 Jun 2020 05:15:05 +0000 Received: from SA0PR16MB3838.namprd16.prod.outlook.com ([fe80::f966:fdd8:1532:ecdd]) by SA0PR16MB3838.namprd16.prod.outlook.com ([fe80::f966:fdd8:1532:ecdd%8]) with mapi id 15.20.3131.020; Fri, 26 Jun 2020 05:15:05 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , kaname nishizuka CC: "dots@ietf.org" Thread-Topic: DOTS Telemetry: Interop Clarification #3 Thread-Index: AdZLJzstzanwENMBRvG6m9wslEq8bAAUJqWg Date: Fri, 26 Jun 2020 05:15:05 +0000 Message-ID: References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action x-originating-ip: [49.37.202.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d5cb442-4d0b-43af-8bb1-08d8198fe302 x-ms-traffictypediagnostic: SA0PR16MB3920: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0446F0FCE1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V2ygj7elXnc1XarydSRyzS9QOWNvoHr3CsR8XHtBWwd2aZrnW0cAfDB+HjvikK752ZWpiFUKYkZgPtZd/2d4PU+MHVJBNtLAcIPB+kVhhEUPBUE+xJIGvU7aS//l0olWa4qjC72tgDR7zVhvXapkW1PAMm6s2OIZ2iy0wG7kPG+K/L6+j3vP5osKhRxFH/UvPzDGjiEUSOqwK6Zvqr+7JP/Dhhxbw1CYWmmcAUCX6qoj3hisGrw81Zy59iBNx3i1Bb8t9DplwFHtBdfRflGvaluks9nEjnIk6xiQg4g0gj5qZ0T56yMi8OttJ0ROQcaYf1rTR4GFTIJZdB3XyPzKFyMaDYXlo6vzsBxr1+QGh4yxrCukBtfb9xAQQ5+/9rO5h0mYkusEAOsgzxcUCFBJPg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR16MB3838.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(136003)(396003)(39860400002)(376002)(32952001)(8676002)(33656002)(9326002)(55016002)(8936002)(52536014)(4326008)(186003)(110136005)(53546011)(316002)(26005)(6506007)(7696005)(478600001)(83380400001)(2906002)(9686003)(66946007)(86362001)(66556008)(5660300002)(66476007)(66446008)(64756008)(71200400001)(76116006)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ndjsQx2Arbpq7uqFRj5LZ5Jtb/gIonQHgfoaZbiNCVb8X0OsXl+gOvjDNXIw90VTzWtLuupyD/pHsgbs4fKv0tSR7jjsQjuV+Kaek1G5zB6X2AA68p/CchMLS8pA3PavmBfCmZDW1LMv9ZfN2mdy8X4B7H3COy6l5eFd4+aywSjxDKbxZPahO/jFrq4tIUAeu2Qn7WzXN0apMvAV7zmNSmaluwvM2soMTleoxIyLc6R5M2zpEsMYY82DdH/OI46wJpNkBM8QxmaBxH8dCOzI+amgcA5WnSMxdEjj0iuriOiKKeectE7SJXa+Oe/e92K1YYfTuVItXsuxDqnqMjBX0JWkksIPijBEGhDjl96nFF+0kNS6i0at4qkT36CEDb4KmdM22oBqn5vCbsIPVIT92Iw/Ef1CLYI0vGlnfLvpkHOnwtr1cqJwpjjkhaOBRYG6F8KFlMpKfjPlt16USCnW4GFEpmscWDImYyfiJ2UN4yY= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR16MB3838.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d5cb442-4d0b-43af-8bb1-08d8198fe302 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2020 05:15:05.0725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: j+7a74nErFAqJAg9pFksfHSC4VLHfXbmgaq5rDHnnRNX8l4ZmqagpTrxvONzOSpknxIja15OGQRqFoPg63Cnzh5oDCh9BSYpMsxcxAX0DArztUI5Tr+6uPYqBvVc7ySo X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR16MB3920 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_SA0PR16MB38388F3CDF8A3298DDEF2543EA930SA0PR16MB3838namp_" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 05:15:13 -0000 --_000_SA0PR16MB38388F3CDF8A3298DDEF2543EA930SA0PR16MB3838namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Med, I don't think the capabilities of the mitigator will get updated dynamicall= y during an active attack to send the new attack details (attack-name) in t= he DOTS signal channel protocol. Cheers, -Tiru From: Dots On Behalf Of mohamed.boucadair@orange.co= m Sent: Friday, June 26, 2020 1:02 AM To: kaname nishizuka Cc: 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 : =3D=3D 3."DOTS agents MUST NOT include 'attack-name' attribute except if the corre= sponding attack mapping details were not shared with the peer DOTS agent". = But how can the DOTS server know they're shared or not? =3D=3D=3D This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else? Thanks. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_SA0PR16MB38388F3CDF8A3298DDEF2543EA930SA0PR16MB3838namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I don’t think the capabilities of the mitigato= r will get updated dynamically during an active attack to send the new atta= ck details (attack-name) in the DOTS signal channel protocol.

 

Cheers,

-Tiru

 

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

 

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

 

Re-,

 

You reported the following in the interim :

=3D=3D

3."DOTS agents MUST NOT include 'attack-name' attribute except i= f the corresponding attack mapping details were not shared with the peer DO= TS agent". But how can the DOTS server know they're shared or not?

=3D=3D=3D

 

This is implementation-specific. The DOTS server may record which ver= sion 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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
--_000_SA0PR16MB38388F3CDF8A3298DDEF2543EA930SA0PR16MB3838namp_-- From nobody Thu Jun 25 23:03:58 2020 Return-Path: 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 5F1333A1144 for ; Thu, 25 Jun 2020 23:03:55 -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 qFfRsTgBgthA for ; Thu, 25 Jun 2020 23:03:53 -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 86D403A0BF5 for ; Thu, 25 Jun 2020 23:03:53 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 49tRCW50w2z5w43; Fri, 26 Jun 2020 08:03:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593151431; bh=9ZTEhBLvnKBuGHoHVV/ADXM/s4OnSpLpomSh5FwaTOU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=c/l7riWALOqPVx9f98zrRIEpPoUwwWibZqMj8nMRCv6qKiVyZM89746jHeys7BQeM WdSL4yqU5bklLYTKwN2jYBLXgxsHYmA/pmBnDSTJ5jqKe1/xumenJPxR+qcl9hBZLH M1Ut0Q8FyGZKmPl9OFkhMT7ZbfBQeMUpOx+EoE+yq2tWczVwmsuIJm+5jQCsnLnXQ3 yfqlAcmYJ5depQiGElLkK9ySTzevy5FwNHvrflAALWfdfRVvJQ2ZmDcyZH8zed3nqz RIO+UTXIBJ1LdC7tFAahLw9F/fOZTYlyS3Ycd+yInoqWpzBHAk8r8+c1mvKX80KZIe tgBlWu3jKZ/2g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 49tRCW41JSzDq87; Fri, 26 Jun 2020 08:03:51 +0200 (CEST) From: To: "Konda, Tirumaleswar Reddy" , "kaname nishizuka" CC: "dots@ietf.org" Thread-Topic: DOTS Telemetry: Interop Clarification #3 Thread-Index: AdZLJzstzanwENMBRvG6m9wslEq8bAAUJqWgAAHUhuA= Date: Fri, 26 Jun 2020 06:03:50 +0000 Message-ID: <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: 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_787AE7BB302AE849A7480A190F8B9330314E78C0OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 06:03:56 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E78C0OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, Not sure to get your comment. Can you please clarify? Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 26 juin 2020 07:15 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 Hi Med, I don't think the capabilities of the mitigator will get updated dynamicall= y during an active attack to send the new attack details (attack-name) in t= he DOTS signal channel protocol. Cheers, -Tiru From: Dots On Behalf Of mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 1:02 AM To: kaname nishizuka Cc: 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 : =3D=3D 3."DOTS agents MUST NOT include 'attack-name' attribute except if the corre= sponding attack mapping details were not shared with the peer DOTS agent". = But how can the DOTS server know they're shared or not? =3D=3D=3D This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else? Thanks. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E78C0OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Not sure to get your comment. Can you pleas= e clarify?

 

Cheers,

Med

 

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

 

Hi Med,

 

I don’t think the capabilities of the mitigato= r will get updated dynamically during an active attack to send the new atta= ck details (attack-name) in the DOTS signal channel protocol.

 

Cheers,

-Tiru

 

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

 

CAUTION: External e= mail. Do not click links or open attachments unless you recognize the sender and know the content i= s safe.

 

Re-,

 

You reported the following in the interim :

=3D=3D

3."DOTS agents MUST NOT include 'attack-name' attrib= ute 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?

=3D=3D=3D

 

This is implementation-specific. The DOTS server may reco= rd 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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E78C0OPEXCAUBMA2corp_-- From nobody Thu Jun 25 23:36:13 2020 Return-Path: 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 C25893A07A9 for ; Thu, 25 Jun 2020 23:36:12 -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, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 2Ggi1OP_UaeF for ; Thu, 25 Jun 2020 23:36:10 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDDA3A0033 for ; Thu, 25 Jun 2020 23:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1593153369; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NxeKoJ/Mf9mEbQsEcsP0VQc88oyaDGsi8VSksyfwW2I=; b=SnSLvvCfO6ABBRqe/mWs/LtI45LF1XVVMLQhvp0AJZq5QLhAL4alVfC5ejtIZtdgMaini2 fX6hx1cGOhXItdJ/8nfg0RxM6o27iPR3I1ZXU5I8+i2G9Z9LmMrt+31RPjb/J4vBf7vV5p vQYmaqWniWkw1GVh+B4PyjdkyynuKLU= Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2107.outbound.protection.outlook.com [104.47.58.107]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-53-JN451VkpNZq7UbxhGXapGA-1; Fri, 26 Jun 2020 02:36:07 -0400 X-MC-Unique: JN451VkpNZq7UbxhGXapGA-1 Received: from SA0PR16MB3838.namprd16.prod.outlook.com (2603:10b6:806:86::9) by SA0PR16MB3725.namprd16.prod.outlook.com (2603:10b6:806:91::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Fri, 26 Jun 2020 06:36:05 +0000 Received: from SA0PR16MB3838.namprd16.prod.outlook.com ([fe80::f966:fdd8:1532:ecdd]) by SA0PR16MB3838.namprd16.prod.outlook.com ([fe80::f966:fdd8:1532:ecdd%8]) with mapi id 15.20.3131.020; Fri, 26 Jun 2020 06:36:05 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , kaname nishizuka CC: "dots@ietf.org" Thread-Topic: DOTS Telemetry: Interop Clarification #3 Thread-Index: AdZLJzstzanwENMBRvG6m9wslEq8bAAUJqWgAAHUhuAAAQ4R4A== Date: Fri, 26 Jun 2020 06:36:05 +0000 Message-ID: References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action x-originating-ip: [49.37.202.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f666249-f573-4df8-b80e-08d8199b33ed x-ms-traffictypediagnostic: SA0PR16MB3725: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0446F0FCE1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sSzAu6cEkJCAnDT+HdavuTbGctw4f6vmA5TPFKn8G5Vk5c5T1tThVT1V4/Fz+hf/9/f50rY5R8d0oegtfNZig7mCmcDmW2W1giqKJkbixGHdZSRxF9+e1ybksSOLtwImR7gs1UQrMjUIyyvT3fW9cp8dDPx1r38C+KUgsg5tvtPOzM0ZIxaKYKcdXHT9yxg5n4p0FhE4WgBD0t6ammPU+jihso4TQWn1ByrLXjFoLVR+OAo8RED2abYN0zwYt0/HcRSpIKBhdV/xff1ZD8dG+0e5VxxJCaAcoyDaPhMXX4Qdm3+HJGp/vgZgPjOGpjLbrdmBnZUjB4MxPq0ou0ssEfFTRHqXtOA3SqUFUt+PdrHGiP4fN3Q1SyZD0PVuWdKvJZnnKBRKeSwgat7e4Z7z5w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR16MB3838.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(136003)(346002)(376002)(32952001)(7696005)(316002)(9686003)(55016002)(33656002)(86362001)(8676002)(52536014)(4326008)(5660300002)(8936002)(6506007)(64756008)(66476007)(2906002)(66946007)(66446008)(66556008)(186003)(53546011)(76116006)(26005)(71200400001)(478600001)(110136005)(83380400001)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VSEakpU8UM9SNyDVrq816bSeXE7ek/RHMnn3ipYDtuZVJ16iw5r18eZjSLxq5SdCUZguXOJGejW2rkPXVsgXEJqSROF4RBsFenL7TIQJsqc+jMQIRGjjqxouhm9Tf9cpy5qtRQF0N0HaLL0VmIuc7TVaG93LhW3ne8zs0MjHRc1a0h5Lm7rWxV8F50gGty7/VbQOjsjy0IuJpORZMcXQnPkKxCJTqElZdxTf0DSmfD2SLYEFzROmm/lcWHXb7E2TuZnv9SMS20SQ4vlSAfeM5JM0zG214lRHOby99AWVv9LxPxVvDmUEvLMKG3SXsTqC1MbsBWvWxqTpQMYCKonswA9S7ungza4wEaxj3kG2sQIxSjsIniVL5clagWFTNR8gqxFRaKNBAvaAL1s5Rj7mNus2GjhVUOvaKcKjm/W82hbGDHNx6zk7hcYDcZawGatQlsiOGMGNuE9dnW6sL3vDUaVsBm02FqJw21/jpdwYa3Gr28tSe3OgK/1qEDXj9a26 x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR16MB3838.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f666249-f573-4df8-b80e-08d8199b33ed X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2020 06:36:05.3732 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gkUH/xhmudgTwqffGje/OkeChy2JlTmWGkj6ns2VzcIPegqWArOrcyEuL+aAc/oKsi/SJ/K/FXbsMOPyKW2wWi+JCCqAimxWUYp/FppPRGQ+1X+UQRRZC6I+M8RpwULp X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR16MB3725 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA40A35 smtp.mailfrom=tirumaleswarreddy_konda@mcafee.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_SA0PR16MB3838F0878467387C54C8C69BEA930SA0PR16MB3838namp_" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 06:36:13 -0000 --_000_SA0PR16MB3838F0878467387C54C8C69BEA930SA0PR16MB3838namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I meant attack mapping details can be sent in the DOTS data channel and no = need to use DOTS signal channel. The capabilities of a DOTS mitigator canno= t be updated dynamically during mitigation that would warrant the need to s= end the attack-description in the DOTS signal channel during attack mitigat= ion. Identifying a new attack requires update to the DOTS mitigator, human-= intervention is required to create the attack description and attack-id. In short, no need overload DOTS signal channel to send the attack descripti= on. -Tiru From: mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 11:34 AM To: Konda, Tirumaleswar Reddy ; kaname = nishizuka 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. ________________________________ Hi Tiru, Not sure to get your comment. Can you please clarify? Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 26 juin 2020 07:15 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 Hi Med, I don't think the capabilities of the mitigator will get updated dynamicall= y during an active attack to send the new attack details (attack-name) in t= he DOTS signal channel protocol. Cheers, -Tiru From: Dots > On Behalf = Of mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 1:02 AM To: kaname nishizuka > Cc: 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 : =3D=3D 3."DOTS agents MUST NOT include 'attack-name' attribute except if the corre= sponding attack mapping details were not shared with the peer DOTS agent". = But how can the DOTS server know they're shared or not? =3D=3D=3D This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else? Thanks. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_SA0PR16MB3838F0878467387C54C8C69BEA930SA0PR16MB3838namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I meant attack mapping details can be sent in the DO= TS data channel and no need to use DOTS signal channel. The capabilities of= a DOTS mitigator cannot be updated dynamically during mitigation that woul= d warrant the need to send the attack-description in the DOTS signal channel during attack mitigation. Identifying a new att= ack requires update to the DOTS mitigator, human-intervention is required t= o create the attack description and attack-id.

 

In short, no need overload DOTS signal channel to se= nd the attack description.

 

-Tiru

 

From: mohamed.boucadair@orange.com <mohame= d.boucadair@orange.com>
Sent: Friday, June 26, 2020 11:34 AM
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.<= /span><= /span>

 

Hi Tiru,

 

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

 

Cheers,

Med

 

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

 

Hi Med,

 

I don’t think the capabilities of the mitigato= r will get updated dynamically during an active attack to send the new atta= ck details (attack-name) in the DOTS signal channel protocol.

 

Cheers,

-Tiru

 

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

 

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

 

Re-,

 

You reported the following in the interim :

=3D=3D

3."DOTS agents MUST NOT include 'attack-name' attribute except i= f the corresponding attack mapping details were not shared with the peer DO= TS agent". But how can the DOTS server know they're shared or not?

=3D=3D=3D

 

This is implementation-specific. The DOTS server may record which ver= sion 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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
--_000_SA0PR16MB3838F0878467387C54C8C69BEA930SA0PR16MB3838namp_-- From nobody Fri Jun 26 00:21:14 2020 Return-Path: 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 DFB633A11A4 for ; Fri, 26 Jun 2020 00:21:12 -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 2dzH4pAm7rFv for ; Fri, 26 Jun 2020 00:21:10 -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 96E2D3A11A2 for ; Fri, 26 Jun 2020 00:21:10 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 49tSwg75bwz2xsg; Fri, 26 Jun 2020 09:21:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593156068; bh=g5CBtPSdF/I5AHdMm83JQGj8hLjQjFLRXy03DGhTcDs=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=AcQg294wlX6vOQOfhnu554Q3toKYLxDEesC0cFWj/H3xBkiweahQGEff9UktGvycs 4Wy+Mrssf3O0G5gYXrvbrqRlzsSUza64wt3Y9noFG9wj6fk7MIQXnGGErm5b/+Qa3G mV+5tw/T2mrK8r3Gz+gQSTuv8kYSdZTOV487CB6rEio/GjkkZm8/cUbrBUwEhp1qbQ FVJ90/SxjGivi576Dzh19OxB8xAkIWmHfnGlo29s5QfgNhOXn7FhMOjZVcTPLOGyNs PLMRBrrGqoAPjrnKfEr1Z3EqEBEZsKms7j7mH29SqjQd03M1jta27h4e/0Tu1kwyfl 8+dCNfAS9NvWg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 49tSwg66kYz3wbB; Fri, 26 Jun 2020 09:21:07 +0200 (CEST) From: To: "Konda, Tirumaleswar Reddy" , "kaname nishizuka" CC: "dots@ietf.org" Thread-Topic: DOTS Telemetry: Interop Clarification #3 Thread-Index: AdZLJzstzanwENMBRvG6m9wslEq8bAAUJqWgAAHUhuAAAQ4R4AABayNQ Date: Fri, 26 Jun 2020 07:21:07 +0000 Message-ID: <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: 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_787AE7BB302AE849A7480A190F8B9330314E7A1FOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 07:21:13 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E7A1FOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 26 juin 2020 08:36 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : 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 m= itigation 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 did= n'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 att= ack-name if attack-details are included in the telemetry data. Identifying a new attack requires update to the DOTS mitigator, human-inter= vention 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 descripti= on. [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 Sent: Friday, June 26, 2020 11:34 AM To: Konda, Tirumaleswar Reddy ; kaname = nishizuka 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. ________________________________ Hi Tiru, Not sure to get your comment. Can you please clarify? Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 26 juin 2020 07:15 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 Hi Med, I don't think the capabilities of the mitigator will get updated dynamicall= y during an active attack to send the new attack details (attack-name) in t= he DOTS signal channel protocol. Cheers, -Tiru From: Dots > On Behalf = Of mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 1:02 AM To: kaname nishizuka > Cc: 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 : =3D=3D 3."DOTS agents MUST NOT include 'attack-name' attribute except if the corre= sponding attack mapping details were not shared with the peer DOTS agent". = But how can the DOTS server know they're shared or not? =3D=3D=3D This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else? Thanks. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E7A1FOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

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

 

I meant attack mapping details can be sent in the DO= TS 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 updat= ed dynamically during mitigation that would warrant the need to send the at= tack-description in the DOTS signal channel during attack mitigation.

[Med] The issue is when the mapping d= etails were updated but the client didn’t retrieved the up-to-date li= st. 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-deta= ils 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 w= hy the mapping details are not in-sync between the client and server.  = ;

 

In short, no need overload DOTS signal channel to se= nd the attack description.

[Med] As you know, the reco we have i= s 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 <mohame= d.boucadair@orange.com>
Sent: Friday, June 26, 2020 11:34 AM
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 e= mail. Do not click links or open attachments unless you recognize the sender and know the content i= s safe.

 

Hi Tiru,

 

Not sure to get your comment. Can you pleas= e clarify?

 

Cheers,

Med

 

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

 

Hi Med,

 

I don’t think the capabilities of the mitigato= r will get updated dynamically during an active attack to send the new atta= ck details (attack-name) in the DOTS signal channel protocol.

 

Cheers,

-Tiru

 

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

 

CAUTION: External e= mail. Do not click links or open attachments unless you recognize the sender and know the content i= s safe.

 

Re-,

 

You reported the following in the interim :

=3D=3D

3."DOTS agents MUST NOT include 'attack-name' attrib= ute 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?

=3D=3D=3D

 

This is implementation-specific. The DOTS server may reco= rd 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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E7A1FOPEXCAUBMA2corp_-- From nobody Fri Jun 26 00:27:24 2020 Return-Path: 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 2C1C73A11A4 for ; Fri, 26 Jun 2020 00:27:23 -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, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 KWXLnR-gdfo4 for ; Fri, 26 Jun 2020 00:27:21 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34963A07CA for ; Fri, 26 Jun 2020 00:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1593156439; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IIjYRitMputfnP50e51Kwneynv2QZUB/Qi91gAuBrd8=; b=RDDZ8r0t2UG+nh5r1mEvGsAOTcPAHndLSYavgPqckNpQGexRSCnUDwDGvKCVAJr9joGVlG iNGlLeruLMo8+yGuMVjP/e9npBCjITG498AYWPQ0ROU0144Juel7DVzZgOI1Rz1CoyZjF6 vc7FrZ6J0XiVV0RDczTGxTcWOzbbxrg= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-299-pTbVtHUUOWOMIYakmyH78Q-1; Fri, 26 Jun 2020 03:27:17 -0400 X-MC-Unique: pTbVtHUUOWOMIYakmyH78Q-1 Received: from BLAPR16MB3827.namprd16.prod.outlook.com (2603:10b6:208:27d::19) by BLAPR16MB3764.namprd16.prod.outlook.com (2603:10b6:208:276::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Fri, 26 Jun 2020 07:27:15 +0000 Received: from BLAPR16MB3827.namprd16.prod.outlook.com ([fe80::9822:7b5d:3976:977e]) by BLAPR16MB3827.namprd16.prod.outlook.com ([fe80::9822:7b5d:3976:977e%7]) with mapi id 15.20.3131.023; Fri, 26 Jun 2020 07:27:15 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , kaname nishizuka CC: "dots@ietf.org" Thread-Topic: DOTS Telemetry: Interop Clarification #3 Thread-Index: AdZLJzstzanwENMBRvG6m9wslEq8bAAUJqWgAAHUhuAAAQ4R4AABayNQAABwD7A= Date: Fri, 26 Jun 2020 07:27:15 +0000 Message-ID: References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action x-originating-ip: [49.37.202.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eae0af35-97b1-4c66-fe1b-08d819a259ce x-ms-traffictypediagnostic: BLAPR16MB3764: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0446F0FCE1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b9j2uxZsyeRGc8x42lCT0thXR5VnHwdHrDRO1ve9GR5VosQbOzgP3aMEZzg8UulDqFyZUlfGsxNRHMntkQ4yOs9gW9NcVvxtGrgInn+isit1FYLeobaCL1NYbtEV2Akrebjwm4aM9UZSVxHKjLrJLIOgN9lhrVwyPzCScVSb5dfK1FyO48D8iny/5nSlayuvY9pPt4vm1UmDeX4Vqdb/LrxZUkMYpPuoxlbzmFIQTmtUHA9e8o3H/s4U/R7ubbS3OjYzKrh/FJt+iMV2eqgRIiD/Ud/lS4UTERIqkkzK2oR/1ywVjuKm+8qPkrGRVG84LWYqB5c6stMQ2axKAYSP0lqawb4EVKono3t6fadGxcfdTD604ZlBvNdl/kBznHLlLR0N7wIsd/JE0AQbaV9tRw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR16MB3827.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(136003)(366004)(376002)(32952001)(5660300002)(66476007)(66446008)(478600001)(8676002)(52536014)(33656002)(4326008)(71200400001)(9686003)(9326002)(83380400001)(7696005)(2906002)(26005)(55016002)(76116006)(66946007)(186003)(64756008)(86362001)(66556008)(110136005)(316002)(6506007)(8936002)(53546011)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RPKpZs1vjCJbYUwyxuulXkeDQooJ8Ujf4hYh5IyI710U6O+ZkckxeqV3yOSwhMlp/yHQv8FvGtewyotBo4ROzQJHkYm5X2OWRnlUjwKZNv+ZPZzU4rm91N2zWfGm2ExBrQgEHKWHUbkhkBexa1ecDbIo4vX6VTLRFsTIS79WpnlJku3XtScdDSI4VIyTjNJ8FbYHDYsioT1OK0rMNOcYZHbp9tHuOLPKiyCSBN5kaES/P2ob6mVdpgqTxkyQBhxvGr4H1IJg1dbH6jkQtl4qD4gFBvVPYCVseLINjjcyDyDItpUvBG7fM1VpqHD9ZFzQzYKw1ZiTHo56t7N0vYx+gJJ6BXuFa5xWsP2asIlWQrpzkTXZ01rLSTiYtkPmnFTvz2itiLBhpt9JDSPxCS6ODxz/s+o5lQyUVeF1HyqD5AJgSRiJgvpe0HFq+DH/sEfNAqQxKK6lLZtptHMgSBPcNQuyJmbp+Btdx1WENa5oIygm8Wi0ecGxXes4cMNwgW07 x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR16MB3827.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eae0af35-97b1-4c66-fe1b-08d819a259ce X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2020 07:27:15.3973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sXv8RhXzN5Y6Lc/inhuBroBllyUnCeXZMjJIUFbjBh5OpipAP7Yc6F4YqVig9DrP+SqdrKj/m6PfpZUZOTuU2X/IraOrbKA4ljqCVGe3gRoVeltGQJLA22IVrvxh5J8O X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR16MB3764 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_BLAPR16MB38278E86C67891BF1449D78BEA930BLAPR16MB3827namp_" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 07:27:23 -0000 --_000_BLAPR16MB38278E86C67891BF1449D78BEA930BLAPR16MB3827namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Med, I prefer avoiding the need to send attack description in the DOTS signal ch= annel. One way is to send the attack-id and last-update timestamp so the pe= er knows whether it has received the latest snapshot or not. Cheers, -Tiru From: mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 12:51 PM To: Konda, Tirumaleswar Reddy ; kaname = nishizuka 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=E9 : vendredi 26 juin 2020 08:36 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : 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 m= itigation 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 did= n'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 att= ack-name if attack-details are included in the telemetry data. Identifying a new attack requires update to the DOTS mitigator, human-inter= vention 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 descripti= on. [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 > Sent: Friday, June 26, 2020 11:34 AM To: Konda, Tirumaleswar Reddy >; kaname nishizuka > 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. ________________________________ Hi Tiru, Not sure to get your comment. Can you please clarify? Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 26 juin 2020 07:15 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 Hi Med, I don't think the capabilities of the mitigator will get updated dynamicall= y during an active attack to send the new attack details (attack-name) in t= he DOTS signal channel protocol. Cheers, -Tiru From: Dots > On Behalf = Of mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 1:02 AM To: kaname nishizuka > Cc: 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 : =3D=3D 3."DOTS agents MUST NOT include 'attack-name' attribute except if the corre= sponding attack mapping details were not shared with the peer DOTS agent". = But how can the DOTS server know they're shared or not? =3D=3D=3D This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else? Thanks. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_BLAPR16MB38278E86C67891BF1449D78BEA930BLAPR16MB3827namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Med,

 

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

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com <mohame= d.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.<= /span><= /span>

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

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

 

I meant attack mapping details can be sent in the DO= TS data channel and no need to use DOTS signal channel.

[Med] Sure. We are not changing this behavior. &n= bsp;

 

The capabilities of a DOTS mitigator cannot be updat= ed dynamically during mitigation that would warrant the need to send the at= tack-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 at= tack occurs, sending the attack-id only won’t be useful for the client; hence the need to send also the attack-name if attack-deta= ils 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 mappi= ng details are not in-sync between the client and server.  =

 

In short, no need overload DOTS signal channel to se= nd the attack description.

[Med] As you know, the reco we have is to avoid s= ending attack-name in the signal channel. There are exceptions where the at= tack-name may be included, though.    

 

-Tiru

 

From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: Friday, June 26, 2020 11:34 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nish= izuka <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.<= /span><= /span>

 

Hi Tiru,

 

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

 

Cheers,

Med

 

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

 

Hi Med,

 

I don’t think the capabilities of the mitigato= r will get updated dynamically during an active attack to send the new atta= ck details (attack-name) in the DOTS signal channel protocol.

 

Cheers,

-Tiru

 

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

 

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

 

Re-,

 

You reported the following in the interim :

=3D=3D

3."DOTS agents MUST NOT include 'attack-name' attribute except i= f the corresponding attack mapping details were not shared with the peer DO= TS agent". But how can the DOTS server know they're shared or not?

=3D=3D=3D

 

This is implementation-specific. The DOTS server may record which ver= sion 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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
--_000_BLAPR16MB38278E86C67891BF1449D78BEA930BLAPR16MB3827namp_-- From nobody Fri Jun 26 00:52:25 2020 Return-Path: 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 ; 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 ; 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 ; 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: To: "Konda, Tirumaleswar Reddy" , "kaname nishizuka" CC: "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> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 07:52:24 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E7A8EOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 channe= l 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 th= e attack details in the signal channel with one exception when an agent det= ects a synch issue. =3D=3D 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. =3D=3D If there is a message size issue, a dots agent can send the telemetry in se= parate messages, use the new bloc options, etc. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 26 juin 2020 09:27 =C0 : 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 ch= annel. One way is to send the attack-id and last-update timestamp so the pe= er knows whether it has received the latest snapshot or not. Cheers, -Tiru From: mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 12:51 PM To: Konda, Tirumaleswar Reddy ; kaname = nishizuka 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=E9 : vendredi 26 juin 2020 08:36 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : 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 m= itigation 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 did= n'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 att= ack-name if attack-details are included in the telemetry data. Identifying a new attack requires update to the DOTS mitigator, human-inter= vention 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 descripti= on. [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 > Sent: Friday, June 26, 2020 11:34 AM To: Konda, Tirumaleswar Reddy >; kaname nishizuka > 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. ________________________________ Hi Tiru, Not sure to get your comment. Can you please clarify? Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : vendredi 26 juin 2020 07:15 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 Hi Med, I don't think the capabilities of the mitigator will get updated dynamicall= y during an active attack to send the new attack details (attack-name) in t= he DOTS signal channel protocol. Cheers, -Tiru From: Dots > On Behalf = Of mohamed.boucadair@orange.com Sent: Friday, June 26, 2020 1:02 AM To: kaname nishizuka > Cc: 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 : =3D=3D 3."DOTS agents MUST NOT include 'attack-name' attribute except if the corre= sponding attack mapping details were not shared with the peer DOTS agent". = But how can the DOTS server know they're shared or not? =3D=3D=3D This is implementation-specific. The DOTS server may record which version o= f 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 ha= ve mind something else? Thanks. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E7A8EOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

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

 

I’m not sure it is useful to send tha= t new attribute in the signal channel as the attack details won’ be u= seful 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.

 

=3D=3D

   When conveying attack detai= ls in DOTS telemetry messages (Sections

   7.2, 7.3, and 8), DOTS agen= ts MUST NOT include 'attack-name'

   attribute except if the cor= responding attack mapping details were not

   shared with the peer DOTS a= gent.

=3D=3D

 

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

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Kon= da@McAfee.com]
Envoy=E9 : vendredi 26 juin 2020 09:27
=C0 : 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 descriptio= n in the DOTS signal channel. One way is to send the attack-id and last-upd= ate timestamp so the peer knows whether it has received the latest snapshot= or not.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com <mohame= d.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 e= mail. Do not click links or open attachments unless you recognize the sender and know the content i= s safe.

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

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

 

I meant attack mapping details can be sent in the DO= TS 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 updat= ed dynamically during mitigation that would warrant the need to send the at= tack-description in the DOTS signal channel during attack mitigation.

[Med] The issue is when the mapping d= etails were updated but the client didn’t retrieved the up-to-date li= st. 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-deta= ils 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 w= hy the mapping details are not in-sync between the client and server.  = ;

 

In short, no need overload DOTS signal channel to se= nd the attack description.

[Med] As you know, the reco we have i= s 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 <mohamed.boucadair@orange.com>
Sent: Friday, June 26, 2020 11:34 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nish= izuka <kaname@nttv6.jp>
Cc: dots@ietf.org
Subject: RE: DOTS Telemetry: Interop Clarification #3

 

CAUTION: External e= mail. Do not click links or open attachments unless you recognize the sender and know the content i= s safe.

 

Hi Tiru,

 

Not sure to get your comment. Can you pleas= e clarify?

 

Cheers,

Med

 

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

 

Hi Med,

 

I don’t think the capabilities of the mitigato= r will get updated dynamically during an active attack to send the new atta= ck details (attack-name) in the DOTS signal channel protocol.

 

Cheers,

-Tiru

 

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

 

CAUTION: External e= mail. Do not click links or open attachments unless you recognize the sender and know the content i= s safe.

 

Re-,

 

You reported the following in the interim :

=3D=3D

3."DOTS agents MUST NOT include 'attack-name' attrib= ute 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?

=3D=3D=3D

 

This is implementation-specific. The DOTS server may reco= rd 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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E7A8EOPEXCAUBMA2corp_-- From nobody Fri Jun 26 03:41:41 2020 Return-Path: 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 B313E3A08FD for ; Fri, 26 Jun 2020 03:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 F_gym9iSx14o for ; Fri, 26 Jun 2020 03:41:36 -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 6803E3A08F6 for ; Fri, 26 Jun 2020 03:41:36 -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 ) id 1jolnX-0001QF-64; Fri, 26 Jun 2020 11:41:31 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , "kaname nishizuka" , References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <25557_1593157938_5EF5A932_25557_94_1_787AE7BB302AE849A7480A190F8B9330314E7A8E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <25557_1593157938_5EF5A932_25557_94_1_787AE7BB302AE849A7480A190F8B9330314E7A8E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 26 Jun 2020 11:41:26 +0100 Message-ID: <080801d64ba6$5810d200$08327600$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0809_01D64BAE.B9DC65F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMQVzkSw5+t7i57rG6sbLPe/e+VwQG84YKvAXQMfC0BrvdSFAHq/x6TAipc4uYDARGzraYW2rCg Content-Language: en-gb Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 10:41:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0809_01D64BAE.B9DC65F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 See inline =20 Regards =20 Jon. =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 26 June 2020 08:52 To: Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #3 =20 Re-, =20 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.=20 =20 Jon> In the attack mapping over the dots data channel I would like to = see =93vendor-name=94 and =93vendor-mapping-last-updated=94. =20 I=92m not sure it is useful to send that new attribute in the signal = channel as the attack details won=92 be useful in the lack of the attack = description. =20 Jon> If a new attack-id has been created and the new attack vector is occurring, but mappings have not been refreshed, then I think that the attack-id should be used over the signal channel. If the receiving DOTS agent is a DOTS client, it can then try to initiate the transfer of a = new mapping over the data channel. If the receiving DOTS agent is a server, = then I can think of no server triggered mechanism that can be used to request = the client to send a new mapping table. However, the client should know it = has a new attack-id =96 hence new mapping =96 and should initiate the = sending of a new mapping. =20 Jon> Worst case is an out of band conversation to determine what this = new attack-id really is. =20 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.=20 =20 =3D=3D 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. =3D=3D =20 If there is a message size issue, a dots agent can send the telemetry in separate messages, use the new bloc options, etc. =20 =20 Jon> I am moving in the direction of attack-name/attack-description = should never be used over the signal channel. Makes things a lot simpler. ~Jon =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : vendredi 26 juin 2020 09:27 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 =20 Hi Med, =20 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. =20 Cheers, -Tiru=20 =20 From: mohamed.boucadair@orange.com =20 Sent: Friday, June 26, 2020 12:51 PM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka Cc: dots@ietf.org Subject: RE: DOTS Telemetry: Interop Clarification #3 =20 CAUTION: External email. Do not click links or open attachments unless = you recognize the sender and know the content is safe. =20 _____ =20 Re-,=20 =20 Please see inline. =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : vendredi 26 juin 2020 08:36 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 =20 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. =20 =20 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.=20 [Med] The issue is when the mapping details were updated but the client didn=92t retrieved the up-to-date list. If an attack occurs, sending the attack-id only won=92t be useful for the client; hence the need to send = also the attack-name if attack-details are included in the telemetry data. =20 =20 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. =20 =20 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. =20 =20 -Tiru =20 From: mohamed.boucadair@orange.com =20 Sent: Friday, June 26, 2020 11:34 AM To: Konda, Tirumaleswar Reddy ; = kaname nishizuka Cc: dots@ietf.org Subject: RE: DOTS Telemetry: Interop Clarification #3 =20 CAUTION: External email. Do not click links or open attachments unless = you recognize the sender and know the content is safe. =20 _____ =20 Hi Tiru,=20 =20 Not sure to get your comment. Can you please clarify? =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : vendredi 26 juin 2020 07:15 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka Cc : dots@ietf.org Objet : RE: DOTS Telemetry: Interop Clarification #3 =20 Hi Med, =20 I don=92t 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.=20 =20 Cheers, -Tiru =20 From: Dots On Behalf Of mohamed..boucadair@orange.com =20 Sent: Friday, June 26, 2020 1:02 AM To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #3 =20 CAUTION: External email. Do not click links or open attachments unless = you recognize the sender and know the content is safe. =20 _____ =20 Re-, =20 You reported the following in the interim : =3D=3D 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? =3D=3D=3D =20 This is implementation-specific. The DOTS server may record which = version of the mapping table it shared with a DOTS client.=20 =20 Do you think that we need to include such details in the spec? or do you have mind something else? =20 Thanks. =20 Cheers, Med =20 _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. ------=_NextPart_000_0809_01D64BAE.B9DC65F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

See = inline

 

Regards

 

Jon.

 

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 26 June 2020 = 08:52
To: Konda, Tirumaleswar Reddy; kaname = nishizuka
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS = Telemetry: Interop Clarification #3

 

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.

 

Jon> In the = attack mapping over the dots data channel I would like to see = “vendor-name” and = “vendor-mapping-last-updated”.

 

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.

 

Jon> = If a new attack-id has been created = and the new attack vector is occurring, but mappings have not been = refreshed, then I think that the attack-id should be used over the = signal channel.=A0 If the receiving DOTS agent is a DOTS client, it can = then try to initiate the transfer of a new mapping over the data = channel. If the receiving DOTS agent is a server, then I can think of no = server triggered mechanism that can be used to request the client to = send a new mapping table.=A0 However, the client should know it has a = new attack-id – hence new mapping – and should initiate the = sending of a new mapping.

 

Jon> Worst case is an = out of band conversation to determine what this new attack-id really = is.

 

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. =

 

=3D=3D

   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.

=3D=3D

 

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

 

Jon> I = am moving in the direction of attack-name/attack-description should = never be used over=A0 the signal channel.=A0 Makes things a lot = simpler.

~Jon

 

Cheers,

Med

 

De : Konda, = Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] =
Envoy=E9 : vendredi 26 juin 2020 = 09:27
=C0 : 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:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : vendredi 26 juin = 2020 08:36
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname = nishizuka
Cc : 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= <mohamed.boucadair@orange.com= >
Sent: Friday, June 26, 2020 11:34 AM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@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.

 

Hi Tiru,

 

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

 

Cheers,

Med

 

De : Konda, = Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : vendredi 26 juin = 2020 07:15
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname = nishizuka
Cc : 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> = On Behalf Of mohamed..boucadair@orange.co= m
Sent: Friday, June 26, 2020 1:02 AM
To: kaname = nishizuka <kaname@nttv6.jp>
Cc: 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 :

=3D=3D

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?

=3D=3D=3D

 

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

 
____________________________________________________________=
_____________________________________________________________<=
/span>
 
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.
____________________________________________________________=
_____________________________________________________________<=
/span>
 
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.
------=_NextPart_000_0809_01D64BAE.B9DC65F0-- From nobody Fri Jun 26 04:32:46 2020 Return-Path: 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 44AF83A1250 for ; Fri, 26 Jun 2020 04:32: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 42oLrW5mHtzW for ; Fri, 26 Jun 2020 04:32:42 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C53D3A109C for ; Fri, 26 Jun 2020 04:32:42 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 49tZVw1zr0z5xfS; Fri, 26 Jun 2020 13:32:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593171160; bh=lvbTouU/tqSO0RDdYEk1grkxtK6HVZjNSiXX19cSdbQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=TxkH/LaxjRDB9C2qpiT1AGah948eVIS1nUhdLQv+WNvaM4/H4aF8C4OHM8eDl+YiE 9YDFBlk+vK+5sAyw/3mZh9bw+lhHEbR8L3/7eCZTb+tNo87KQ8ZTsPCthK/LzUs9dD 5cpzHfXG5Gc24UYbKajSR8x4UfSYZDAWBddw7EL1JxIqEO9aihceZQ3kHt7gmfreXe yHH4U6ckSljzTF1CL7ffO3546b6YFqwHhf8iIZmLqmGrg85mX9SDZPRca9MYAt/O10 x3xfxwEsRqYhR5aLdvvuIdG+RgePSE5Rs6gj5nGHrWgp4vdwlQcWZril+SX9xcQ/yi 55rltoNtLI7yg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 49tZVw0h7gzCqk7; Fri, 26 Jun 2020 13:32:40 +0200 (CEST) From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] DOTS Telemetry: Interop Clarification #3 Thread-Index: AQMQVzkSw5+t7i57rG6sbLPe/e+VwQG84YKvAXQMfC0BrvdSFAHq/x6TAipc4uYDARGzraYW2rCggAAcAAA= Date: Fri, 26 Jun 2020 11:32:39 +0000 Message-ID: <11184_1593171160_5EF5DCD8_11184_207_1_787AE7BB302AE849A7480A190F8B9330314E7C2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <25557_1593157938_5EF5A932_25557_94_1_787AE7BB302AE849A7480A190F8B9330314E7A8E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <080801d64ba6$5810d200$08327600$@jpshallow.com> In-Reply-To: <080801d64ba6$5810d200$08327600$@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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314E7C2FOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 11:32:44 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E7C2FOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 26 juin 2020 12:41 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #3 Hi All, See inline Regards Jon. From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 26 June 2020 08:52 To: Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #3 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 channe= l extension. Jon> In the attack mapping over the dots data channel I would like to see "= vendor-name" and "vendor-mapping-last-updated". [Med] Works for me as well 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. Jon> If a new attack-id has been created and the new attack vector is occur= ring, but mappings have not been refreshed, then I think that the attack-id= should be used over the signal channel. If the receiving DOTS agent is a = DOTS client, it can then try to initiate the transfer of a new mapping over= the data channel. [Med] ... which will fail. If the receiving DOTS agent is a server, then I can think of no server trig= gered mechanism that can be used to request the client to send a new mappin= g table. However, the client should know it has a new attack-id - hence ne= w mapping - and should initiate the sending of a new mapping. [Med] which it needs to do anyway before an attack happens. We do already h= ave the following: The DOTS client uses the PUT request to modify its vendor attack mapping details maintained by the DOTS server (e.g., add a new mapping). Jon> Worst case is an out of band conversation to determine what this new a= ttack-id really is. 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 th= e attack details in the signal channel with one exception when an agent det= ects a synch issue. =3D=3D 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. =3D=3D If there is a message size issue, a dots agent can send the telemetry in se= parate messages, use the new bloc options, etc. Jon> I am moving in the direction of attack-name/attack-description should = never be used over the signal channel. Makes things a lot simpler. [Med] Going that direction has many implications: =B7 Mandate the data channel, which is against what we set in the a= rch spec: "As illustrated in Figure 2, there are two interfaces between a DOTS server and a DOTS client; a signal channel and (optionally) a data ^^^^^^^^^^^^^^^^ channel." =B7 Change the following to a MUST In order to optimize the size of telemetry data conveyed over the DOTS signal channel, DOTS agents MAY use the DOTS data channel [RFC8783] to exchange vendor-specific attack mapping details (that is, {vendor identifier, attack identifier} =3D=3D> attack description). And so on. The current approach in the draft accommodates all these concerns. ~Jon ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E7C2FOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 26 juin 2020 12:41
=C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kan= ame nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #3

 

Hi All,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon.

&n= bsp;

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 26 June 2020 08:52
To: Konda, Tirumaleswar Reddy; kaname nishizuka
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #3

 

Re-,

 

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

 

Jon> In the attack mapping over the dots d= ata channel I would like to see “vendor-name” and “vendor= -mapping-last-updated”.

[Med] Works for me as = well

 

I’m not sure it is useful to send tha= t new attribute in the signal channel as the attack details won’ be u= seful in the lack of the attack description.

 

Jon> If a new attack-id has been created a= nd the new attack vector is occurring, but mappings have not been refreshed= , then I think that the attack-id should be used over the signal channel.  If the receiving DOTS agent is a DOTS = client, it can then try to initiate the transfer of a new mapping over the = data channel.

[Med] … which wi= ll fail.

 

If the = receiving DOTS agent is a server, then I can think of no server triggered m= echanism that can be used to request the client to send a new mapping table= .  However, the client should know it has a new attack-id – hence new mapping – and should initiate = the sending of a new mapping.

[Med] which it needs t= o do anyway before an attack happens. We do already have the following:

 

   The DOTS client uses the PU= T request to modify its vendor attack

   mapping details maintained = by the DOTS server (e.g., add a new

   mapping).=

&n= bsp;

Jon>= Worst case is an out of band conversation to determine what this new attac= k-id really is.

 

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.

 

=3D=3D

   When conveying attack detai= ls in DOTS telemetry messages (Sections

   7.2, 7.3, and 8), DOTS agen= ts MUST NOT include 'attack-name'

   attribute except if the cor= responding attack mapping details were not

   shared with the peer DOTS a= gent.

=3D=3D

 

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

 

Jon> I am moving in= the direction of attack-name/attack-description should never be used over&= nbsp; the signal channel.  Makes things a lot simpler.

[Med] Going that direction has many i= mplications:

=B7         Mandate the data channel, whi= ch is against what we set in the arch spec:

 

   “As illustrated in Fi= gure 2, there are two interfaces between a DOTS

   server and a DOTS client; a= signal channel and (optionally) a data

      &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; ^^^^^^^^^^^^^^^^

   channel.”<= /span>

 

=B7         Change the following to a MUS= T

 

 &nb= sp; In order to optimize the size of telemetry data conveyed over the<= /o:p>

 &nb= sp; DOTS signal channel, DOTS agents MAY use the DOTS data channel

 &nb= sp; [RFC8783] to exchange vendor-specific attack mapping details (that=

   is, {vendor identifier, = attack identifier} =3D=3D> attack description).

 

And so on.

 

The current approach in the draft accommoda= tes all these concerns.

 

~Jon=

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E7C2FOPEXCAUBMA2corp_-- From nobody Fri Jun 26 05:11:07 2020 Return-Path: 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 D05593A1292 for ; Fri, 26 Jun 2020 05:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 W65S1mQfFvrU for ; Fri, 26 Jun 2020 05:11:02 -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 6483A3A1298 for ; Fri, 26 Jun 2020 05:11:02 -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 ) id 1jonC4-0001Uu-SL; Fri, 26 Jun 2020 13:10:56 +0100 From: "Jon Shallow" To: , "kaname nishizuka" , References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 26 Jun 2020 13:10:52 +0100 Message-ID: <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_084B_01D64BBB.38002730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4sce6iu+YFA Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 12:11:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_084B_01D64BBB.38002730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Med, I think that this refers several places. 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes. Here we do an efficacy update of what the client is seeing happen to a specific resource. If the client now does a GET against the same resource - what is returned - the last efficacy update or the current state of mitigation as seen by the DOTS server? 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the client to update the tmid with some information. This includes an attack-detail. When the client wants to see what is happening with this "tmid", it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'. Which attack-detail is returned - the one from the PUT or the ongoing situation? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Kaname, We discussed this issue in the interim: == Current Uri-Path can't distinguish telemetry resources posted by the client or created by the server. -Those are totally different resources. For example, Uri-Query won't be applicable to the telemetry resources posted by the client. == Can you please identify precisely which parts of the text need to be updated? Thank you 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. ------=_NextPart_000_084B_01D64BBB.38002730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I think that this refers = several places.

 

1.       = Efficacy = updates.  E.g.  Figure 45: An Example of Mitigation Efficacy = Update with Telemetry  Attributes. Here we do an efficacy update of = what the client is seeing happen to a specific resource.  If the = client now does a GET against the same resource – what is returned = – the last efficacy update or the current state of mitigation as = seen by the DOTS server?

 

2.       = Also, = Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the = client to update the tmid with some information.  This includes an = attack-detail.  When the client wants to see what is happening with = this “tmid”, it does a Figure 40: GET to Subscribe to = Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which = attack-detail is returned – the one from the PUT or the ongoing = situation?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 25 June 2020 = 20:29
To: kaname nishizuka
Cc: = dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi Kaname, =

 

We discussed this issue in the interim:

 

=3D=3D

Current Uri-Path can't = distinguish telemetry resources posted by the client or created by the = server.

–Those are totally different = resources.

For example, Uri-Query won't be = applicable to the telemetry resources posted by the = client.

=3D=3D

 

Can you please identify = precisely which parts of the text need to be = updated?

 

Thank you

 

Cheers,

Med

 

____________________________________________________________=
_____________________________________________________________<=
/span>
 
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.
------=_NextPart_000_084B_01D64BBB.38002730-- From nobody Fri Jun 26 05:48:06 2020 Return-Path: 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 80C033A0D38 for ; Fri, 26 Jun 2020 05:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 1OuDp9H2RasP for ; Fri, 26 Jun 2020 05:48:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3433A0D2C for ; Fri, 26 Jun 2020 05:48:01 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 49tc9r13WPz51nm for ; Fri, 26 Jun 2020 14:48:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593175680; bh=8o0w1vUI0wKuNMXIoBt5ThwND0/pi9Oc1/onkB/TJko=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=acmzeEYGuoZbAJtLATNYRd+7v/JDTWh4tmfakppjYoXQdvF1LYAtmGcE8eV2XlNGq cFMTV3GG+bdDUwDhsHnqu/Lm+MlEvd7T87T7ofVWPxnJOxB7R/AoHk3K76rCC0nuc+ FTtffgvDPzahGi8/rmOjdqJShnmNcdXoQnRFyBKUTJih4v/kNbuqFPCuS4JHF7274j X4Fqsp2oZQfsw9p6FZ6DZwi7Gku7OUd25z8+FhKv4MmxFTGpiK/c0sPPxeJp2mPZve +FCmIRw31Id31EWMF9Prz8I5ywmwOR3UQuDRGzynRSvMFBkAO3elRj2EfRoWKYyGf7 TlHXsJ0wOhnMw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 49tc9r1FhczFpWV for ; Fri, 26 Jun 2020 14:48:00 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: 128-255 key value range for telemetry attributes (was RE: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt Thread-Index: AdZLuAU659Z1O89LSKyJqwqrIWFCmg== Date: Fri, 26 Jun 2020 12:47:59 +0000 Message-ID: <18857_1593175680_5EF5EE80_18857_151_1_787AE7BB302AE849A7480A190F8B9330314E7D28@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] 128-255 key value range for telemetry attributes (was RE: I-D Action: draft-ietf-dots-telemetry-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 12:48:05 -0000 Hi all,=20 We discussed yesterday the proposal to use 128-255 as comprehension-optiona= l range for telemetry attributes. The issue was initially discussed below.= =20=20 If we hear no objection, we will update the draft to implement this proposa= l. If implemented, the telemetry draft will be updating RFC8782, which is f= ine.=20 We do have new 117 attributes in the telemetry spec, but we are considering= reducing that list in compliance with RFC7951 rules.=20=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: lundi 3 f=E9vrier 2020 10:37 > =C0=A0: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > Objet=A0: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt >=20 > Hi all, >=20 > FYI, a review from Jon is available at: https://github.com/boucadair/draf= t- > dots-telemetry/raw/master/DOTS%20Telemetry%2001-rev%20Jon-res%20Med.docx >=20 > -02 will integrate almost all comments from Jon. Please find below some > points we would like to hear more from the working group: >=20 > (1) key value range for telemetry: Jon raised this point "These keys > requires 3 bytes - and telemetry information is going to be difficult to > fit into a packet. I appreciate that comprehension-required > Is for numbers less than 0x8000 - perhaps the comprehension-required range > is reduced and also has a section higher up so the total of 0x8000 still > stands so less bytes can be used here." >=20 > +----------------------+-------+-------+------------+---------------+ > | Parameter Name | CBOR | CBOR | Change | Specification | > | | Key | Major | Controller | Document(s) | > | | Value | Type | | | > +----------------------+-------+-------+------------+---------------+ > | ietf-dots-signal-cha | 32776 | 5 | IESG | [RFCXXXX] | > | nnel:telemetry | | | | | >=20 > Med: This is a major one. We need to assess the gain, but it is possible = in > theory to update our assignment policies and reassign, e.g., 128-255 range > to be comprehension-optional (specific for telemetry). This would mean th= at > the telemetry spec will be tagged as updating the base signal channel spe= c. > We need more discussion. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Fri Jun 26 07:24:46 2020 Return-Path: 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 8E97E3A00D6 for ; Fri, 26 Jun 2020 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 7FTzHJHhdjMt for ; Fri, 26 Jun 2020 07:24:43 -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 0F1493A00D4 for ; Fri, 26 Jun 2020 07:24:42 -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 ) id 1jopHS-0001bT-1N; Fri, 26 Jun 2020 15:24:38 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , "kaname nishizuka" , References: <27464_1593113494_5EF4FB96_27464_425_1_787AE7BB302AE849A7480A190F8B9330314E7645@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18913_1593151431_5EF58FC7_18913_57_1_787AE7BB302AE849A7480A190F8B9330314E78C0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29225_1593156067_5EF5A1E3_29225_308_1_787AE7BB302AE849A7480A190F8B9330314E7A1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <25557_1593157938_5EF5A932_25557_94_1_787AE7BB302AE849A7480A190F8B9330314E7A8E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <080801d64ba6$5810d200$08327600$@jpshallow.com> <11184_1593171160_5EF5DCD8_11184_207_1_787AE7BB302AE849A7480A190F8B9330314E7C2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <11184_1593171160_5EF5DCD8_11184_207_1_787AE7BB302AE849A7480A190F8B9330314E7C2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 26 Jun 2020 15:24:33 +0100 Message-ID: <08a101d64bc5$83285f70$89791e50$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08A2_01D64BCD.E4EF1160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMQVzkSw5+t7i57rG6sbLPe/e+VwQG84YKvAXQMfC0BrvdSFAHq/x6TAipc4uYDARGzrQJZHADbAbGx0D2l9q6R4A== Content-Language: en-gb Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 14:24:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08A2_01D64BCD.E4EF1160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med et al, =20 Please see inline Jon1> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 26 June 2020 12:33 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; = dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #3 =20 Hi Jon, =20 Please see inline.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 26 juin 2020 12:41 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname = nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #3 =20 Hi All, =20 See inline =20 Regards =20 Jon. =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 26 June 2020 08:52 To: Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #3 =20 Re-, =20 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.=20 =20 Jon> In the attack mapping over the dots data channel I would like to = see =93vendor-name=94 and =93vendor-mapping-last-updated=94. [Med] Works for me as well=20 =20 I=92m not sure it is useful to send that new attribute in the signal = channel as the attack details won=92 be useful in the lack of the attack = description. =20 Jon> If a new attack-id has been created and the new attack vector is occurring, but mappings have not been refreshed, then I think that the attack-id should be used over the signal channel. If the receiving DOTS agent is a DOTS client, it can then try to initiate the transfer of a = new mapping over the data channel. [Med] =85 which will fail.=20 Jon1> Yes =96 if we are into pipe losses and data channel fails to work. However, the likelihood is that the lossy pipe is inbound, so then the client will never see the packet containing the new attack-id. I still think that if the DOTS client sees an unrecognized attack-id it should = try to get the latest mappings. =20 If the receiving DOTS agent is a server, then I can think of no server triggered mechanism that can be used to request the client to send a new mapping table.. However, the client should know it has a new attack-id = =96 hence new mapping =96 and should initiate the sending of a new mapping. [Med] which it needs to do anyway before an attack happens. Jon1> It is possible that an attack is under way, someone does some = analysis and either comes up with a new attack-id to describe what is going on or does a code update and then sends the new mapping =96 the attack has not ceased=85. =20 [Med] We do already have the following:=20 =20 The DOTS client uses the PUT request to modify its vendor attack mapping details maintained by the DOTS server (e.g., add a new mapping). Jon1> Agreed. As a side note, we do not give a PUT example which has vendor-id=3D in the URL. =20 Jon> Worst case is an out of band conversation to determine what this = new attack-id really is. =20 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.=20 =20 =3D=3D 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. =3D=3D =20 If there is a message size issue, a dots agent can send the telemetry in separate messages, use the new bloc options, etc. =20 =20 Jon> I am moving in the direction of attack-name/attack-description = should never be used over the signal channel. Makes things a lot simpler. [Med] Going that direction has many implications:=20 =B7 Mandate the data channel, which is against what we set in = the arch spec:=20 =20 =93As illustrated in Figure 2, there are two interfaces between a = DOTS server and a DOTS client; a signal channel and (optionally) a data ^^^^^^^^^^^^^^^^ channel.=94 =20 =B7 Change the following to a MUST =20 In order to optimize the size of telemetry data conveyed over the DOTS signal channel, DOTS agents MAY use the DOTS data channel [RFC8783] to exchange vendor-specific attack mapping details (that is, {vendor identifier, attack identifier} =3D=3D> attack = description). =20 Jon1> I had forgotten that the data channel was optional. Sending the vendor mapping over the signal channel could be done =96 most likely has = to be in peace time unless we can use the new block options. My vendor = mapping takes about 10k bytes. ~Jon1 =20 And so on.=20 =20 The current approach in the draft accommodates all these concerns.=20 =20 ~Jon =20 _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. ------=_NextPart_000_08A2_01D64BCD.E4EF1160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med et al,

 

Please see inline = Jon1>

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 26 June 2020 = 12:33
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname = nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: = Interop Clarification #3

 

Hi = Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = vendredi 26 juin 2020 12:41
=C0 : BOUCADAIR Mohamed = TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; = dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop = Clarification #3

 

Hi = All,

 

See = inline

 

Regards

 

Jon.

 

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 26 June 2020 = 08:52
To: Konda, Tirumaleswar Reddy; kaname = nishizuka
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS = Telemetry: Interop Clarification #3

 

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.

 

Jon> = In the attack mapping over the dots = data channel I would like to see “vendor-name” and = “vendor-mapping-last-updated”.

[Med] Works for me as well

 

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.

 

Jon> = If a new attack-id has been created = and the new attack vector is occurring, but mappings have not been = refreshed, then I think that the attack-id should be used over the = signal channel.  If the receiving DOTS agent is a DOTS client, it = can then try to initiate the transfer of a new mapping over the data = channel.

[Med] … which = will fail.

Jon1> Yes – if we are into pipe losses and data = channel fails to work.=A0 However, the likelihood is that the lossy pipe = is inbound, so then the client will never see the packet containing the = new attack-id.=A0 I still think that if the DOTS client sees an = unrecognized attack-id it should try to get the latest = mappings.

 

If the receiving DOTS = agent is a server, then I can think of no server triggered mechanism = that can be used to request the client to send a new mapping = table..  However, the client should know it has a new attack-id = – hence new mapping – and should initiate the sending of a = new mapping.

[Med] which it needs = to do anyway before an attack happens.

Jon1> It is possible that an attack is under way, = someone does some analysis and either comes up with a new attack-id to = describe what is going on or does a code update and then sends the new = mapping – the attack has not = ceased….

 

[Med] We do already have = the following:

 

   The = DOTS client uses the PUT request to modify its vendor = attack

   = mapping details maintained by the DOTS server (e.g., add a = new

   = mapping).

Jon1> Agreed.=A0 As a side note, we do not give a PUT = example which has vendor-id=3D in the URL.

 

Jon> Worst case is an = out of band conversation to determine what this new attack-id really = is.

 

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. =

 

=3D=3D

   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.

=3D=3D

 

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

 

Jon> I = am moving in the direction of attack-name/attack-description should = never be used over  the signal channel.  Makes things a lot = simpler.

[Med] = Going that direction has many implications: =

=B7         = Mandate the data = channel, which is against what we set in the arch spec: =

 

   = “As illustrated in Figure 2, there are two interfaces between a = DOTS

   server = and a DOTS client; a signal channel and (optionally) a = data

           &= nbsp;           &n= bsp;           &nb= sp;          = ^^^^^^^^^^^^^^^^

   channel.”

 

=B7         = Change the following = to a MUST

 

   In order = to optimize the size of telemetry data conveyed over = the

   DOTS = signal channel, DOTS agents MAY use the DOTS data = channel

   [RFC8783] = to exchange vendor-specific attack mapping details = (that

   is, {vendor identifier, attack = identifier} =3D=3D> attack = description).

 

Jon1> I had forgotten that the data channel was = optional.=A0 Sending the vendor mapping over the signal channel could be = done – most likely has to be in peace time unless we can use the = new block options.=A0 My vendor mapping takes about 10k = bytes.

~Jon1

 

And so on.

 

The current approach in the draft accommodates all = these concerns.

 

~Jon

 

____________________________________________________________=
_____________________________________________________________<=
/span>
 
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.
------=_NextPart_000_08A2_01D64BCD.E4EF1160-- From nobody Sun Jun 28 19:08:32 2020 Return-Path: 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 1AFB43A1028 for ; Sun, 28 Jun 2020 19:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nttv6.jp 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 jbPWNqhNRycd for ; Sun, 28 Jun 2020 19:08:29 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 105F73A1015 for ; Sun, 28 Jun 2020 19:08:28 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id E152825F6BB; Mon, 29 Jun 2020 11:08:26 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1593396506; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=flOdKasStvBzBoQlvFkNyiWxBd4Cp6G+v+up7KdcYxc=; b=DhGQ/1CUaJjHYRzY7xlAIFUYzrCnRZQ8WblOrpGgmxzkUiLHKdgKRAGjXEakiea2qJR0o8 e8Egwcnvm7464dtR/koDfsyIWrXy7aoVDxt8QYeeQrvDEv1vdbRhZrJFWG8JcMczIalVKj 1MrHDzfxl0QCk1Fq9iyc7TLSusgsQp8= Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id AB81175900F; Mon, 29 Jun 2020 11:08:26 +0900 (JST) To: Jon Shallow , mohamed.boucadair@orange.com, dots@ietf.org References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> From: kaname nishizuka Message-ID: <1a429aca-5e63-188d-5d44-148fc6b38ee2@nttv6.jp> Date: Mon, 29 Jun 2020 11:08:26 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------6636C5370BF848CBABB2432D" Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 02:08:31 -0000 This is a multi-part message in MIME format. --------------6636C5370BF848CBABB2432D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Med, Jon, Thanks for describing the issue, Jon. One way is separating the URI-path for "the client's PUT/GET" and "GET for the values seen by the DOTS server". The other way is treating Total Traffic/Attack Details telemetry data by the DOTS client PUT as a hint which will not be stored in the DOTS server. However, in that situation, the DOTS client DELETE will mean nothing. regards, Kaname On 2020/06/26 21:10, Jon Shallow wrote: > > Hi Med, > > I think that this refers several places. > > 1.Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes. Here we do an efficacy update of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource – what is returned – the last efficacy update or the current state of mitigation as seen by the DOTS server? > > 2.Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the client to update the tmid with some information.  This includes an attack-detail.  When the client wants to see what is happening with this “tmid”, it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which attack-detail is returned – the one from the PUT or the ongoing situation? > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *mohamed.boucadair@orange.com > *Sent:* 25 June 2020 20:29 > *To:* kaname nishizuka > *Cc:* dots@ietf.org > *Subject:* [Dots] DOTS Telemetry: Interop Clarification #1 > > Hi Kaname, > > We discussed this issue in the interim: > > == > > Current Uri-Path can't distinguish telemetry resources posted by the client or created by the server. > > –Those are totally different resources. > > For example, Uri-Query won't be applicable to the telemetry resources posted by the client. > > == > > Can you please identify precisely which parts of the text need to be updated? > > Thank you > > 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. --------------6636C5370BF848CBABB2432D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Med, Jon,

Thanks for describing the issue, Jon.

One way is separating the URI-path for "the client's PUT/GET" and "GET for the values seen by the DOTS server".

The other way is treating Total Traffic/Attack Details telemetry data by the DOTS client PUT as a hint which will not be stored in the DOTS server.
However, in that situation, the DOTS client DELETE will mean nothing.

regards,
Kaname

On 2020/06/26 21:10, Jon Shallow wrote:

Hi Med,

 

I think that this refers several places.

 

1.       Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Efficacy Update with Telemetry  Attributes. Here we do an efficacy update of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource – what is returned – the last efficacy update or the current state of mitigation as seen by the DOTS server?

 

2.       Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the client to update the tmid with some information.  This includes an attack-detail.  When the client wants to see what is happening with this “tmid”, it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which attack-detail is returned – the one from the PUT or the ongoing situation?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Kaname,

 

We discussed this issue in the interim:

 

==

Current Uri-Path can't distinguish telemetry resources posted by the client or created by the server.

–Those are totally different resources.

For example, Uri-Query won't be applicable to the telemetry resources posted by the client.

==

 

Can you please identify precisely which parts of the text need to be updated?

 

Thank you

 

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.

--------------6636C5370BF848CBABB2432D-- From nobody Sun Jun 28 23:38:28 2020 Return-Path: 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 D95D73A08EE for ; Sun, 28 Jun 2020 23:38:25 -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 Q2t6WGK8M72T for ; Sun, 28 Jun 2020 23:38:24 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DFA3A08EC for ; Sun, 28 Jun 2020 23:38:23 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 49wHqy0mQJzyd9; Mon, 29 Jun 2020 08:38:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593412702; bh=gWsyH7QJYwED4dlnDSOyf9Bd/edfLWcAmJSf6Odfw6o=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=xWNDoRwhR/YNLqsOqzy3bGiXAR1XxdtgqDZ9s0v1qFD3HsSPZlxpE5GBqm5GCuetM fSmNpxCmmfucqXF/YRZHEJwpp1/ZSUkAJ3bUYQGSsEX22ZlGxlWqYm1Q7zRxjBxo5h A/ONIUrCacisrhDlB74t1JUd+rIK27hq9nlskXsrhSBvhMSg33h+ZOo8OKoSK8jyt8 EdcudOyFj434c1mT43ONoTKdafpP/Vb4VDz/S53XoQyIXKAKiI9MVYu2/FB9Tnozln OH6zAV6egFHLRlqEGoHSMeE88B0WcJApTDUiUT7X2ea2PxrrdQJwRrdw6OcHjOHxTf 1EANvZHdRRCHw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 49wHqx73fvz1xp4; Mon, 29 Jun 2020 08:38:21 +0200 (CEST) From: To: Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] DOTS Telemetry: Interop Clarification #1 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4sce6iu+YFAgARc7cA= Date: Mon, 29 Jun 2020 06:38:21 +0000 Message-ID: <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> In-Reply-To: <084a01d64bb2$d63a86b0$82af9410$@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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314E8989OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 06:38:26 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E8989OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, all, The server will return the data that match the filters included in the GET = that triggered the response. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 26 juin 2020 14:11 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, I think that this refers several places. 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Effic= acy Update with Telemetry Attributes. Here we do an efficacy update of wha= t the client is seeing happen to a specific resource. If the client now do= es a GET against the same resource - what is returned - the last efficacy u= pdate or the current state of mitigation as seen by the DOTS server? 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry a= llows the client to update the tmid with some information. This includes a= n attack-detail. When the client wants to see what is happening with this = "tmid", it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Not= ifications for a Specific 'tmid'. Which attack-detail is returned - the on= e from the PUT or the ongoing situation? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Kaname, We discussed this issue in the interim: =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the client= or created by the server. -Those are totally different resources. For example, Uri-Query won't be applicable to the telemetry resources poste= d by the client. =3D=3D Can you please identify precisely which parts of the text need to be update= d? Thank you Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E8989OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon, all,

 

The server will return the data that match = the filters included in the GET that triggered the response.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 26 juin 2020 14:11
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.or= g
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

I think= that this refers several places.

&n= bsp;

1.       Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Eff= icacy Update with Telemetry  Attributes. Here we do an efficacy update= of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource = 211; what is returned – the last efficacy update or the current state= of mitigation as seen by the DOTS server?

&n= bsp;

2.       Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows th= e client to update the tmid with some information.  This includes an a= ttack-detail.  When the client wants to see what is happening with this “tmid”, it does a Figure 40: GET t= o Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.&= nbsp; Which attack-detail is returned – the one from the PUT or the o= ngoing situation?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop Clarification #1<= /span>

 

Hi Kaname,

 

We discussed this issue in the interim:=

 

=3D=3D

Current Uri-Path can't distinguish telemetry resources po= sted by the client or created by the server.

–Those are totally different resources.

For example, Uri-Query won't be applicable to the telemet= ry resources posted by the client.

=3D=3D

 

Can you please identify precisely which parts of the text= need to be updated?

 

Thank you

 

Cheers,

Med

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E8989OPEXCAUBMA2corp_-- From nobody Mon Jun 29 02:13:06 2020 Return-Path: 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 CD0B13A0CBE for ; Mon, 29 Jun 2020 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 KywWK7sdjkNi for ; Mon, 29 Jun 2020 02:13:03 -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 324B23A0CBC for ; Mon, 29 Jun 2020 02:12:59 -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 ) id 1jppqQ-00041V-Kq; Mon, 29 Jun 2020 10:12:54 +0100 From: "Jon Shallow" To: , "kaname nishizuka" , References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 29 Jun 2020 10:12:47 +0100 Message-ID: <0ad501d64df5$74b89b30$5e29d190$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AD6_01D64DFD.D67E89D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4scewEFmq9oAkUV0A6omSuj4A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 09:13:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0AD6_01D64DFD.D67E89D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 So for absolute clarity, the DOTS server will return the values it has internally determined (from DOTS mitigator etc.), not those provided by = the DOTS client using a PUT, as modified by the GET Query filters. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 June 2020 07:38 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Jon, all, =20 The server will return the data that match the filters included in the = GET that triggered the response.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 26 juin 2020 14:11 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Med, =20 I think that this refers several places. =20 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes. Here we do an efficacy = update of what the client is seeing happen to a specific resource. If the client = now does a GET against the same resource =96 what is returned =96 the last = efficacy update or the current state of mitigation as seen by the DOTS server? =20 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation = Telemetry allows the client to update the tmid with some information. This = includes an attack-detail. When the client wants to see what is happening with = this =93tmid=94, it does a Figure 40: GET to Subscribe to Telemetry = Asynchronous Notifications for a Specific 'tmid'. Which attack-detail is returned = =96 the one from the PUT or the ongoing situation? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Kaname,=20 =20 We discussed this issue in the interim: =20 =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the = client or created by the server. =96Those are totally different resources.=20 For example, Uri-Query won't be applicable to the telemetry resources = posted by the client. =3D=3D =20 Can you please identify precisely which parts of the text need to be updated? =20 Thank you=20 =20 Cheers, Med =20 _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. ------=_NextPart_000_0AD6_01D64DFD.D67E89D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

So for absolute clarity, = the DOTS server will return the values it has internally determined = (from DOTS mitigator etc.), not those provided by the DOTS client using = a PUT, as modified by the GET Query filters.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 29 June 2020 = 07:38
To: Jon Shallow; kaname nishizuka; = dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi Jon, all,

 

The server will return the data that match = the filters included in the GET that triggered the response. =

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = vendredi 26 juin 2020 14:11
=C0 : BOUCADAIR Mohamed = TGI/OLN; kaname nishizuka; dots@ietf.org
Objet : RE: = [Dots] DOTS Telemetry: Interop Clarification = #1

 

Hi Med,

 

I think that this refers = several places.

 

1.       = Efficacy = updates.  E.g.  Figure 45: An Example of Mitigation Efficacy = Update with Telemetry  Attributes. Here we do an efficacy update of = what the client is seeing happen to a specific resource.  If the = client now does a GET against the same resource – what is returned = – the last efficacy update or the current state of mitigation as = seen by the DOTS server?

 

2.       = Also, = Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the = client to update the tmid with some information.  This includes an = attack-detail.  When the client wants to see what is happening with = this “tmid”, it does a Figure 40: GET to Subscribe to = Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which = attack-detail is returned – the one from the PUT or the ongoing = situation?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 25 June 2020 = 20:29
To: kaname nishizuka
Cc: = dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi Kaname, =

 

We discussed = this issue in the interim:

 

=3D=3D

Current = Uri-Path can't distinguish telemetry resources posted by the client or = created by the server.

–Those = are totally different resources.

For example, Uri-Query won't be applicable to the = telemetry resources posted by the client.

=3D=3D

 

Can you please = identify precisely which parts of the text need to be = updated?

 

Thank you =

 

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.
------=_NextPart_000_0AD6_01D64DFD.D67E89D0-- From nobody Mon Jun 29 03:44:58 2020 Return-Path: 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 0E4E93A0D86 for ; Mon, 29 Jun 2020 03:44:56 -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 pnAe4g9pzqyW for ; Mon, 29 Jun 2020 03:44:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1003A0D77 for ; Mon, 29 Jun 2020 03:44:53 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 49wPJN1wm0z5vlk; Mon, 29 Jun 2020 12:44:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593427492; bh=4ZTbn1oNryshpiey33uij9wJSWrTapul+jdxceSQzFA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Og2vS0yLoUKQ470OX0FLw/D/RMMlu/Pa86b9/Y8pU6VLdyb8j/Rn2Hq7UPZKcSdu4 uEUE/WhUdV8EjSSctEfNVPqgCtw/31kM/eogzOGYIq8R6iU81SEG8W1BPcsRtlNGtv /PmmJq/DNDjhiray+Dxy+fDVoaaqTcBi+Xk3Kw2sG2fFkKMEGlgkYj8kIEDmycI4Ly 8EDRuT5Gst9iefdWnglxFqMx7t6fvbOa1F41HdS8pb+p67irDxAOU58DxE8m0su5t8 Kvdx12iUd1fBEwJj9Qf1MdjvRKCkcjWyJA8hWodjg6d0hvPneLSukGooon5UrUTT3l kSLByw+sn/dZQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 49wPJN15jSz1xpL; Mon, 29 Jun 2020 12:44:52 +0200 (CEST) From: To: Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] DOTS Telemetry: Interop Clarification #1 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4scewEFmq9oAkUV0A6omSuj4IAAGCGg Date: Mon, 29 Jun 2020 10:44:51 +0000 Message-ID: <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ad501d64df5$74b89b30$5e29d190$@jpshallow.com> In-Reply-To: <0ad501d64df5$74b89b30$5e29d190$@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_787AE7BB302AE849A7480A190F8B9330314E8BF2OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 10:44:56 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E8BF2OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, It is the other way around: the server will filter out the data it will ret= urn to match the filters conveyed in GET. So, =B7 if we refer to your case (1), the PUT used for efficacy update = does not interfere with the handling of GET to retrieve the server's status. =B7 if we refer to your case (2), the PUT in Figure 36 sets the tar= get (telemetry) scope. So for any telemetry-related GET, the server will on= ly return data that is bound to the target as set in the PUT. These data is= further filtered out based of any uri-query in the GET. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 29 juin 2020 11:13 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, So for absolute clarity, the DOTS server will return the values it has inte= rnally determined (from DOTS mitigator etc.), not those provided by the DOT= S client using a PUT, as modified by the GET Query filters. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 June 2020 07:38 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Jon, all, The server will return the data that match the filters included in the GET = that triggered the response. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 26 juin 2020 14:11 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, I think that this refers several places. 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Effic= acy Update with Telemetry Attributes. Here we do an efficacy update of wha= t the client is seeing happen to a specific resource. If the client now do= es a GET against the same resource - what is returned - the last efficacy u= pdate or the current state of mitigation as seen by the DOTS server? 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry a= llows the client to update the tmid with some information. This includes a= n attack-detail. When the client wants to see what is happening with this = "tmid", it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Not= ifications for a Specific 'tmid'. Which attack-detail is returned - the on= e from the PUT or the ongoing situation? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Kaname, We discussed this issue in the interim: =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the client= or created by the server. -Those are totally different resources. For example, Uri-Query won't be applicable to the telemetry resources poste= d by the client. =3D=3D Can you please identify precisely which parts of the text need to be update= d? Thank you Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E8BF2OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

It is the other way around: the server will f= ilter out the data it will return to match the filters conveyed in GET.

 

So,

=B7         if we refer to your case (1), the PUT= used for efficacy update does not interfere with the handling of GET to re= trieve the server’s status.

=B7         if we refer to your case (2), the PUT= in Figure 36 sets the target (telemetry) scope. So for any telemetry-relat= ed GET, the server will only return data that is bound to the target as set in the PUT. These data is further filtered out based = of any uri-query in the GET.    

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 29 juin 2020 11:13
=C0 : BOUCADAIR Mohamed TGI/OLN;= kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

So for = absolute clarity, the DOTS server will return the values it has internally = determined (from DOTS mitigator etc.), not those provided by the DOTS clien= t using a PUT, as modified by the GET Query filters.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 June 2020 07:38
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Jon, all,

 

The server will return the data that match = the filters included in the GET that triggered the response.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 26 juin 2020 14:11
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.or= g
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

I think= that this refers several places.

&n= bsp;

1.       Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Eff= icacy Update with Telemetry  Attributes. Here we do an efficacy update= of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource = 211; what is returned – the last efficacy update or the current state= of mitigation as seen by the DOTS server?

&n= bsp;

2.       Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows th= e client to update the tmid with some information.  This includes an a= ttack-detail.  When the client wants to see what is happening with this “tmid”, it does a Figure 40: GET t= o Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.&= nbsp; Which attack-detail is returned – the one from the PUT or the o= ngoing situation?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop Clarification #1<= /span>

 

Hi Kaname,

 

We discussed this issue in the interim:=

 

=3D=3D

Current Uri-Path can't distinguish telemetry resources po= sted by the client or created by the server.

–Those are totally different resources.

For example, Uri-Query won't be applicable to the telemet= ry resources posted by the client.

=3D=3D

 

Can you please identify precisely which parts of the text= need to be updated?

 

Thank you

 

Cheers,

Med

 

__________________________________________________________=
_______________________________________________________________<=
/span>
 
Ce message et ses pieces jointes peuvent contenir des info=
rmations 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 al=
tere, 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 aut=
horisation.


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

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


Thank you.


__________________________________________________________=
_______________________________________________________________<=
/span>
 
Ce message et ses pieces jointes peuvent contenir des info=
rmations 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 al=
tere, 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 aut=
horisation.


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

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


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E8BF2OPEXCAUBMA2corp_-- From nobody Mon Jun 29 04:41:42 2020 Return-Path: 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 49C6D3A0E1A for ; Mon, 29 Jun 2020 04:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 sgmoeYHmyIPP for ; Mon, 29 Jun 2020 04:41:37 -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 325FB3A0E12 for ; Mon, 29 Jun 2020 04:41:34 -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 ) id 1jpsAE-00047t-7b; Mon, 29 Jun 2020 12:41:30 +0100 From: "Jon Shallow" To: , "kaname nishizuka" , References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ad501d64df5$74b89b30$5e29d190$@jpshallow.com> <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 29 Jun 2020 12:41:22 +0100 Message-ID: <0b1401d64e0a$36c332d0$a4499870$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B15_01D64E12.98892170" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4scewEFmq9oAkUV0A4B4ImsbALKkiyFqHP409A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 11:41:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B15_01D64E12.98892170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 I=92m still confused =96 could be that we are talking cross purposes = here. =20 See inline Jon> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 June 2020 11:45 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Jon,=20 =20 It is the other way around: the server will filter out the data it will return to match the filters conveyed in GET. Jon> That filtering I agree with. It just is what is the data source = used for the server GET response. =20 So,=20 =B7 if we refer to your case (1), the PUT used for efficacy = update does not interfere with the handling of GET to retrieve the server=92s = status. Jon> Figure 45 PUT includes "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabit-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] Jon> What does the DOTS server respond with for a GET =96 the value = =93900 megabit-ps=94 or what the DOTS server (as told by DOTS mitigator etc.) = thinks is actually happening =96 e.g. =9311 gigabit-ps=94 because a lot of = attack traffic is being dropped by the DOTS mitigators? Just to be absolutely sure =96 = the server is getting its status from multiple sources =96 which status does = it report on in the GET. =B7 if we refer to your case (2), the PUT in Figure 36 sets the = target (telemetry) scope. So for any telemetry-related GET, the server will = only return data that is bound to the target as set in the PUT. These data is further filtered out based of any uri-query in the GET.=20 Jon> Figure 36 PUT goes beyond defining the target (alias-name in this = case) and includes "attack-detail": [ { "vendor-id": 1234, "attack-id": 77, "start-time": "1957811234", "attack-severity": "high" } ] Jon> So what is returned in the GET for this target =96 this attack = detail or the attack detail that the DOTS server is being told by the DOTS = mitigators =96 which could include the same vendor-id + attack-id (but maybe with a different start time)? ~Jon =20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 29 juin 2020 11:13 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Med, =20 So for absolute clarity, the DOTS server will return the values it has internally determined (from DOTS mitigator etc.), not those provided by = the DOTS client using a PUT, as modified by the GET Query filters. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 June 2020 07:38 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Jon, all, =20 The server will return the data that match the filters included in the = GET that triggered the response.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 26 juin 2020 14:11 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Med, =20 I think that this refers several places. =20 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes. Here we do an efficacy = update of what the client is seeing happen to a specific resource. If the client = now does a GET against the same resource =96 what is returned =96 the last = efficacy update or the current state of mitigation as seen by the DOTS server? =20 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation = Telemetry allows the client to update the tmid with some information. This = includes an attack-detail. When the client wants to see what is happening with = this =93tmid=94, it does a Figure 40: GET to Subscribe to Telemetry = Asynchronous Notifications for a Specific 'tmid'. Which attack-detail is returned = =96 the one from the PUT or the ongoing situation? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Kaname,=20 =20 We discussed this issue in the interim: =20 =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the = client or created by the server. =96Those are totally different resources.=20 For example, Uri-Query won't be applicable to the telemetry resources = posted by the client. =3D=3D =20 Can you please identify precisely which parts of the text need to be updated? =20 Thank you=20 =20 Cheers, Med =20 _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. ------=_NextPart_000_0B15_01D64E12.98892170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I’m still confused = – could be that we are talking cross purposes = here.

 

See inline = Jon>

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 29 June 2020 = 11:45
To: Jon Shallow; kaname nishizuka; = dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi = Jon,

 

It is the other way around: the server will = filter out the data it will return to match the filters conveyed in = GET.

Jon> That filtering I agree with.=A0 It just = is what is the data source used for the server GET = response.

 

So,

=B7         = if we refer to = your case (1), the PUT used for efficacy update does not interfere with = the handling of GET to retrieve the server’s = status.

Jon> Figure 45 PUT = includes

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "ietf-dots-telemetry:total-attack-traffic": = [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = {

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "ietf-dots-telemetry:unit": = "megabit-ps",

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "ietf-dots-telemetry:mid-percentile-g": = "900"

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = }

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ]

Jon>=A0 What does the DOTS server respond = with for a GET – the value “900 megabit-ps” or what = the DOTS server (as told by DOTS mitigator etc.) thinks is actually = happening – e.g. “11 gigabit-ps” because a lot of = attack traffic is being dropped by the DOTS mitigators?=A0 Just to be = absolutely sure – the server is getting its status from multiple = sources – which status does it report on in the = GET.

=

=B7         = if we refer to = your case (2), the PUT in Figure 36 sets the target (telemetry) scope. = So for any telemetry-related GET, the server will only return data that = is bound to the target as set in the PUT. These data is further filtered = out based of any uri-query in the GET.

Jon> = Figure 36 PUT goes beyond defining the target (alias-name in this case) = and includes

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "attack-detail": [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = {

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "vendor-id": 1234,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "attack-id": 77,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "start-time": "1957811234",

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "attack-severity": "high"

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = }

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ]

Jon> So what is returned in the GET for this = target – this attack detail or the attack detail that the DOTS = server is being told by the DOTS mitigators – which could include = the same vendor-id + attack-id (but maybe with a different start = time)?

~Jon   

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = lundi 29 juin 2020 11:13
=C0 : BOUCADAIR = Mohamed TGI/OLN; = kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS = Telemetry: Interop Clarification #1

 

Hi = Med,

 

So for absolute clarity, = the DOTS server will return the values it has internally determined = (from DOTS mitigator etc.), not those provided by the DOTS client using = a PUT, as modified by the GET Query filters.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 29 June 2020 = 07:38
To: Jon Shallow; kaname nishizuka; = dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi Jon, all,

 

The server will return the data that match = the filters included in the GET that triggered the response. =

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = vendredi 26 juin 2020 14:11
=C0 : BOUCADAIR Mohamed = TGI/OLN; kaname nishizuka; dots@ietf.org
Objet : RE: = [Dots] DOTS Telemetry: Interop Clarification = #1

 

Hi Med,

 

I think that this refers = several places.

 

1.       = Efficacy = updates.  E.g.  Figure 45: An Example of Mitigation Efficacy = Update with Telemetry  Attributes. Here we do an efficacy update of = what the client is seeing happen to a specific resource.  If the = client now does a GET against the same resource – what is returned = – the last efficacy update or the current state of mitigation as = seen by the DOTS server?

 

2.       = Also, = Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the = client to update the tmid with some information.  This includes an = attack-detail.  When the client wants to see what is happening with = this “tmid”, it does a Figure 40: GET to Subscribe to = Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which = attack-detail is returned – the one from the PUT or the ongoing = situation?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 25 June 2020 = 20:29
To: kaname nishizuka
Cc: = dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi Kaname, =

 

We discussed = this issue in the interim:

 

=3D=3D

Current = Uri-Path can't distinguish telemetry resources posted by the client or = created by the server.

–Those = are totally different resources.

For example, Uri-Query won't be applicable to the = telemetry resources posted by the client.

=3D=3D

 

Can you please = identify precisely which parts of the text need to be = updated?

 

Thank you =

 

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.
____________________________________________________________=
_____________________________________________________________<=
/span>
 
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.
------=_NextPart_000_0B15_01D64E12.98892170-- From nobody Mon Jun 29 05:20:45 2020 Return-Path: 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 D36093A0E68 for ; Mon, 29 Jun 2020 05:20:43 -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 O0HPTbeX1nju for ; Mon, 29 Jun 2020 05:20:42 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5253A0E58 for ; Mon, 29 Jun 2020 05:20:41 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 49wRQv6hkXz8syR; Mon, 29 Jun 2020 14:20:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593433239; bh=kvQWPa5jvCQm9j+c7vUjiZjy3rUQjycbdKT0nkY1ydo=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=BCCPMe7GG8zt+ttTP+U6p5GRoV2RXTTQs7Ukz6Xi/rwPjRMtMGGhGUnidZVPwsUH0 e7cL4/GPivq5qfZ15uHpnLGIcYHdh1KarlDQQxwLaXwyWmHvn9E2sEgPePXUwIU3Gn eOhprv+TnYZq/g1koihZDgYi9JQIxuvFYOdyj5ytb+ez7rSTB3zZawEjUBxXdUx5Z9 ltV/k7NM/E9TgmbJGX9jW/u17RLKd+Y6pecbvnNQ+v35KfkUeZOPajesm4CVSDWLtv O1g+UfmrCxAUk28teDZpg/FUmwC3+p3PMTjgN0tib5kxw3ZsuU/hOkEYb2gyOh9a2J rxxFayFjtplbg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 49wRQv0xZczCqkK; Mon, 29 Jun 2020 14:20:39 +0200 (CEST) From: To: Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] DOTS Telemetry: Interop Clarification #1 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4scewEFmq9oAkUV0A4B4ImsbALKkiyFqHP409CAAA4dAA== Date: Mon, 29 Jun 2020 12:20:38 +0000 Message-ID: <27502_1593433239_5EF9DC97_27502_120_16_787AE7BB302AE849A7480A190F8B9330314E8CFE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ad501d64df5$74b89b30$5e29d190$@jpshallow.com> <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0b1401d64e0a$36c332d0$a4499870$@jpshallow.com> In-Reply-To: <0b1401d64e0a$36c332d0$a4499870$@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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314E8CFEOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 12:20:44 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E8CFEOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 29 juin 2020 13:41 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, I'm still confused - could be that we are talking cross purposes here. See inline Jon> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 June 2020 11:45 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Jon, It is the other way around: the server will filter out the data it will ret= urn to match the filters conveyed in GET. Jon> That filtering I agree with. [Med] OK. It just is what is the data source used for the server GET response. So, =B7 if we refer to your case (1), the PUT used for efficacy update = does not interfere with the handling of GET to retrieve the server's status. Jon> Figure 45 PUT includes "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabit-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] Jon> What does the DOTS server respond with for a GET - the value "900 meg= abit-ps" or what the DOTS server (as told by DOTS mitigator etc.) thinks is= actually happening - e.g. "11 gigabit-ps" because a lot of attack traffic = is being dropped by the DOTS mitigators? Just to be absolutely sure - the = server is getting its status from multiple sources - which status does it r= eport on in the GET. [Med] The server will report the status it is seeing (reported from mitigat= ors), not the one inferred from the efficacy update from the client. We are= not changing the behavior we have in the base spec. =B7 if we refer to your case (2), the PUT in Figure 36 sets the tar= get (telemetry) scope. So for any telemetry-related GET, the server will on= ly return data that is bound to the target as set in the PUT. These data is= further filtered out based of any uri-query in the GET. Jon> Figure 36 PUT goes beyond defining the target (alias-name in this case= ) and includes "attack-detail": [ { "vendor-id": 1234, "attack-id": 77, "start-time": "1957811234", "attack-severity": "high" } ] Jon> So what is returned in the GET for this target - this attack detail or= the attack detail that the DOTS server is being told by the DOTS mitigator= s - which could include the same vendor-id + attack-id (but maybe with a di= fferent start time)? [Med] Like above, the status that will be reported is the one from mitigato= rs. ~Jon Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 29 juin 2020 11:13 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, So for absolute clarity, the DOTS server will return the values it has inte= rnally determined (from DOTS mitigator etc.), not those provided by the DOT= S client using a PUT, as modified by the GET Query filters. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 June 2020 07:38 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Jon, all, The server will return the data that match the filters included in the GET = that triggered the response. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 26 juin 2020 14:11 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, I think that this refers several places. 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Effic= acy Update with Telemetry Attributes. Here we do an efficacy update of wha= t the client is seeing happen to a specific resource. If the client now do= es a GET against the same resource - what is returned - the last efficacy u= pdate or the current state of mitigation as seen by the DOTS server? 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry a= llows the client to update the tmid with some information. This includes a= n attack-detail. When the client wants to see what is happening with this = "tmid", it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Not= ifications for a Specific 'tmid'. Which attack-detail is returned - the on= e from the PUT or the ongoing situation? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Kaname, We discussed this issue in the interim: =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the client= or created by the server. -Those are totally different resources. For example, Uri-Query won't be applicable to the telemetry resources poste= d by the client. =3D=3D Can you please identify precisely which parts of the text need to be update= d? Thank you Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E8CFEOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 29 juin 2020 13:41
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.or= g
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

I’= ;m still confused – could be that we are talking cross purposes here.=

&n= bsp;

See inl= ine Jon>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 June 2020 11:45
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Jon,

 

It is the other way around: the server will f= ilter out the data it will return to match the filters conveyed in GET.

Jon> That filtering= I agree with.

[Med] OK.

  It just is what= is the data source used for the server GET response.

 

So,

=B7         if we refer to your case (1), the PUT= used for efficacy update does not interfere with the handling of GET to re= trieve the server’s status.

Jon> Figure 45 PUT = includes

           "i= etf-dots-telemetry:total-attack-traffic": [

           &n= bsp; {

           &n= bsp;   "ietf-dots-telemetry:unit": "megabit-ps&quo= t;,

           &n= bsp;   "ietf-dots-telemetry:mid-percentile-g": "90= 0"

           &n= bsp; }

   &nbs= p;       ]

Jon>  What doe= s the DOTS server respond with for a GET – the value “900 megab= it-ps” or what the DOTS server (as told by DOTS mitigator etc.) think= s is actually happening – e.g. “11 gigabit-ps” because a = lot of attack traffic is being dropped by the DOTS mitigators?  Just to be a= bsolutely sure – the server is getting its status from multiple sourc= es – which status does it report on in the GET.

[Med] The server will report the status= it is seeing (reported from mitigators), not the one inferred from the eff= icacy update from the client. We are not changing the behavior we have in the base spec.

 

=B7         if we refer to your case (2), the PUT= in Figure 36 sets the target (telemetry) scope. So for any telemetry-relat= ed GET, the server will only return data that is bound to the target as set in the PUT. These data is further filtered out based = of any uri-query in the GET.

Jon> Figure 36 PUT = goes beyond defining the target (alias-name in this case) and includes=

           "a= ttack-detail": [

           &n= bsp; {

           &n= bsp;   "vendor-id": 1234,

           &n= bsp;   "attack-id": 77,

           &n= bsp;   "start-time": "1957811234",=

           &n= bsp;   "attack-severity": "high"

           &n= bsp; }

   &nbs= p;       ]

Jon> So what is ret= urned in the GET for this target – this attack detail or the attack d= etail that the DOTS server is being told by the DOTS mitigators – whi= ch could include the same vendor-id + attack-id (but maybe with a different start time)?

[Med] Like above, the status that will = be reported is the one from mitigators.   <= /b>

 

~Jon   

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 29 juin 2020 11:13
=C0 : BOUCADAIR Mohamed TGI/OLN;= kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

So for = absolute clarity, the DOTS server will return the values it has internally = determined (from DOTS mitigator etc.), not those provided by the DOTS clien= t using a PUT, as modified by the GET Query filters.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 June 2020 07:38
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Jon, all,

 

The server will return the data that match = the filters included in the GET that triggered the response.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 26 juin 2020 14:11
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.or= g
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

I think= that this refers several places.

&n= bsp;

1.       Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Eff= icacy Update with Telemetry  Attributes. Here we do an efficacy update= of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource = 211; what is returned – the last efficacy update or the current state= of mitigation as seen by the DOTS server?

&n= bsp;

2.       Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows th= e client to update the tmid with some information.  This includes an a= ttack-detail.  When the client wants to see what is happening with this “tmid”, it does a Figure 40: GET t= o Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.&= nbsp; Which attack-detail is returned – the one from the PUT or the o= ngoing situation?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop Clarification #1<= /span>

 

Hi Kaname,

 

We discussed this issue in the interim:=

 

=3D=3D

Current Uri-Path can't distinguish telemetry resources po= sted by the client or created by the server.

–Those are totally different resources.

For example, Uri-Query won't be applicable to the telemet= ry resources posted by the client.

=3D=3D

 

Can you please identify precisely which parts of the text= need to be updated?

 

Thank you

 

Cheers,

Med

 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E8CFEOPEXCAUBMA2corp_-- From nobody Mon Jun 29 06:39:28 2020 Return-Path: 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 A675E3A0E8C; Mon, 29 Jun 2020 06:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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=smyslov.net 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 drlCEOVb-xuw; Mon, 29 Jun 2020 06:39:21 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 830293A0E9D; Mon, 29 Jun 2020 06:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qg/PrdCgeWn6ZU2GWkEtfbMG5E9iFaQXAEyp9JgDo+g=; b=MQp8fSWCGePWj6omUAr6YixDi0 j5kCkv9Kp8Y5FpKjfXjPnxug0VbE/D/pA1H+C14xWAwcqzLgApiEluq0BAaHEaGYcIeab3E2zY4Z/ fHt8PZ5xgyATTJnD2y9OCE50SOmWWVQkM1Dif13elxVUzgHllAMnR5niNjsm9wwFwM9D0JtpVmtzW PX8vAMqPHzsCzRV0jcn8mfihV2mEGmcIaIpIzknnsJrAdX5RCcfpSMHvIqmFcsW3rrZETHOMNYEGG y8XGXd5NSX4OD2NgSsfNQI7Q2VX59FgIki10uUB2qk5ag6+X3gz5xwpL9JgOv1E9xozAgJzZWalkQ GdVwfrQw==; Received: from [82.138.51.3] (port=53932 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jpu0F-00051Z-QT; Mon, 29 Jun 2020 09:39:20 -0400 From: "Valery Smyslov" To: Cc: , Date: Mon, 29 Jun 2020 16:39:17 +0300 Message-ID: <107f01d64e1a$b16daf00$14490d00$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdZOGh2suVM9N2ujReOTLtdrtiFE5A== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [Dots] Virtual Interim Meeting minutes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 13:39:26 -0000 Hi, minutes of the last Virtual Interim DOTS meeting are available on the datatracker (thanks to Wei Pan for taking them): https://datatracker.ietf.org/meeting/interim-2020-dots-01/materials/minutes-interim-2020-dots-01-202006250600.txt If you have any corrections, please send them to the chairs. Regards, Frank & Valery. From nobody Mon Jun 29 07:31:36 2020 Return-Path: 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 1C7273A0FB7 for ; Mon, 29 Jun 2020 07:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 5yt9lJrEEKJV for ; Mon, 29 Jun 2020 07:31:31 -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 E44323A0FAE for ; Mon, 29 Jun 2020 07:31:30 -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 ) id 1jpuof-0004EW-SN; Mon, 29 Jun 2020 15:31:26 +0100 From: "Jon Shallow" To: , "kaname nishizuka" , References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ad501d64df5$74b89b30$5e29d190$@jpshallow.com> <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0b1401d64e0a$36c332d0$a4499870$@jpshallow.com> <27502_1593433239_5EF9DC97_27502_120_16_787AE7BB302AE849A7480A190F8B9330314E8CFE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <27502_1593433239_5EF9DC97_27502_120_16_787AE7BB302AE849A7480A190F8B9330314E8CFE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 29 Jun 2020 15:31:18 +0100 Message-ID: <0b6f01d64e21$f3c6d5f0$db5481d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B70_01D64E2A.558E7240" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4scewEFmq9oAkUV0A4B4ImsbALKkiyFARsEWX0BV16v26hgmA9A Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 14:31:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B70_01D64E2A.558E7240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 I think that it is worth adding a note for clarity such as =20 OLD Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notification from the DOTS Server NEW Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notification from the DOTS Server =20 Note: Any information uploaded by a PUT (see Figure 36) will not be = included in such a response. END =20 and =20 OLD Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes NEW Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes =20 Note: Any information retrieved by a GET command for this =91mid=92 will = not include any efficacy update information. END =20 =20 Regards =20 Jon =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 June 2020 13:21 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Re-,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 29 juin 2020 13:41 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Med, =20 I=92m still confused =96 could be that we are talking cross purposes = here. =20 See inline Jon> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 June 2020 11:45 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Jon,=20 =20 It is the other way around: the server will filter out the data it will return to match the filters conveyed in GET. Jon> That filtering I agree with. [Med] OK. It just is what is the data source used for the server GET response. =20 So,=20 =B7 if we refer to your case (1), the PUT used for efficacy = update does not interfere with the handling of GET to retrieve the server=92s = status. Jon> Figure 45 PUT includes "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabit-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] Jon> What does the DOTS server respond with for a GET =96 the value = =93900 megabit-ps=94 or what the DOTS server (as told by DOTS mitigator etc.) = thinks is actually happening =96 e.g. =9311 gigabit-ps=94 because a lot of = attack traffic is being dropped by the DOTS mitigators? Just to be absolutely sure =96 = the server is getting its status from multiple sources =96 which status does = it report on in the GET. [Med] The server will report the status it is seeing (reported from mitigators), not the one inferred from the efficacy update from the = client. We are not changing the behavior we have in the base spec.=20 =20 =B7 if we refer to your case (2), the PUT in Figure 36 sets the = target (telemetry) scope. So for any telemetry-related GET, the server will = only return data that is bound to the target as set in the PUT. These data is further filtered out based of any uri-query in the GET.=20 Jon> Figure 36 PUT goes beyond defining the target (alias-name in this = case) and includes "attack-detail": [ { "vendor-id": 1234, "attack-id": 77, "start-time": "1957811234", "attack-severity": "high" } ] Jon> So what is returned in the GET for this target =96 this attack = detail or the attack detail that the DOTS server is being told by the DOTS = mitigators =96 which could include the same vendor-id + attack-id (but maybe with a different start time)? [Med] Like above, the status that will be reported is the one from mitigators. =20 =20 ~Jon =20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 29 juin 2020 11:13 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Med, =20 So for absolute clarity, the DOTS server will return the values it has internally determined (from DOTS mitigator etc.), not those provided by = the DOTS client using a PUT, as modified by the GET Query filters. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 June 2020 07:38 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Jon, all, =20 The server will return the data that match the filters included in the = GET that triggered the response.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 26 juin 2020 14:11 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Med, =20 I think that this refers several places. =20 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes. Here we do an efficacy = update of what the client is seeing happen to a specific resource. If the client = now does a GET against the same resource =96 what is returned =96 the last = efficacy update or the current state of mitigation as seen by the DOTS server? =20 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation = Telemetry allows the client to update the tmid with some information. This = includes an attack-detail. When the client wants to see what is happening with = this =93tmid=94, it does a Figure 40: GET to Subscribe to Telemetry = Asynchronous Notifications for a Specific 'tmid'. Which attack-detail is returned = =96 the one from the PUT or the ongoing situation? =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 =20 Hi Kaname,=20 =20 We discussed this issue in the interim: =20 =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the = client or created by the server. =96Those are totally different resources.=20 For example, Uri-Query won't be applicable to the telemetry resources = posted by the client. =3D=3D =20 Can you please identify precisely which parts of the text need to be updated? =20 Thank you=20 =20 Cheers, Med =20 _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. ------=_NextPart_000_0B70_01D64E2A.558E7240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I think that it is worth = adding a note for clarity such as

 

OLD

=A0=A0=A0=A0 Figure 43: = Message Body of a Pre-or-Ongoing-Mitigation = Telemetry

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Notification from the DOTS Server

NEW

=A0=A0=A0=A0 Figure 43: = Message Body of a Pre-or-Ongoing-Mitigation = Telemetry

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Notification from the DOTS Server

 

Note: Any information = uploaded by a PUT (see Figure 36) will not be included in such a = response.

END

 

and

 

OLD

=A0=A0=A0 Figure 45: An = Example of Mitigation Efficacy Update with = Telemetry

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Attributes

NEW

=A0=A0=A0 Figure 45: An = Example of Mitigation Efficacy Update with = Telemetry

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Attributes

 

Note: Any information = retrieved by a GET command for this ‘mid’ will not include = any efficacy update information.

END

 

 

Regards

 

Jon

 

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 29 June 2020 = 13:21
To: Jon Shallow; kaname nishizuka; = dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = lundi 29 juin 2020 13:41
=C0 : BOUCADAIR Mohamed TGI/OLN; = kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS = Telemetry: Interop Clarification #1

 

Hi = Med,

 

I’m still confused = – could be that we are talking cross purposes here.

 

See inline = Jon>

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 29 June 2020 = 11:45
To: Jon Shallow; kaname nishizuka; = dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi = Jon,

 

It is the other way around: the server will = filter out the data it will return to match the filters conveyed in = GET.

Jon> That filtering I agree with.

[Med] OK.

  It = just is what is the data source used for the server GET = response.

 

So,

=B7         = if we refer to = your case (1), the PUT used for efficacy update does not interfere with = the handling of GET to retrieve the server’s = status.

Jon> Figure 45 PUT = includes

        &= nbsp;  "ietf-dots-telemetry:total-attack-traffic": = [

        &= nbsp;    {

        &= nbsp;      = "ietf-dots-telemetry:unit": = "megabit-ps",

        &= nbsp;      = "ietf-dots-telemetry:mid-percentile-g": = "900"

        &= nbsp;    }

        &= nbsp;  ]

Jon>  What does the DOTS = server respond with for a GET – the value “900 = megabit-ps” or what the DOTS server (as told by DOTS mitigator = etc.) thinks is actually happening – e.g. “11 = gigabit-ps” because a lot of attack traffic is being dropped by = the DOTS mitigators?  Just to be absolutely sure – the server = is getting its status from multiple sources – which status does it = report on in the GET.

[Med] The server will report the status it is = seeing (reported from mitigators), not the one inferred from the = efficacy update from the client. We are not changing the behavior we = have in the base spec.

 

=B7         = if we refer to = your case (2), the PUT in Figure 36 sets the target (telemetry) scope. = So for any telemetry-related GET, the server will only return data that = is bound to the target as set in the PUT. These data is further filtered = out based of any uri-query in the GET.

Jon> = Figure 36 PUT goes beyond defining the target (alias-name in this case) = and includes

        &= nbsp;  "attack-detail": [

        &= nbsp;    {

        &= nbsp;      "vendor-id": = 1234,

        &= nbsp;      "attack-id": = 77,

        &= nbsp;      "start-time": = "1957811234",

        &= nbsp;      "attack-severity": = "high"

        &= nbsp;    }

        &= nbsp;  ]

Jon> So what is returned in the = GET for this target – this attack detail or the attack detail that = the DOTS server is being told by the DOTS mitigators – which could = include the same vendor-id + attack-id (but maybe with a different start = time)?

[Med] Like above, the status that will be = reported is the one from mitigators. =   

 

~Jon   

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = lundi 29 juin 2020 11:13
=C0 : BOUCADAIR = Mohamed TGI/OLN; = kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS = Telemetry: Interop Clarification #1

 

Hi = Med,

 

So for absolute clarity, = the DOTS server will return the values it has internally determined = (from DOTS mitigator etc.), not those provided by the DOTS client using = a PUT, as modified by the GET Query filters.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 29 June 2020 = 07:38
To: Jon Shallow; kaname nishizuka; = dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi Jon, all,

 

The server will return the data that match = the filters included in the GET that triggered the response. =

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = vendredi 26 juin 2020 14:11
=C0 : BOUCADAIR Mohamed = TGI/OLN; kaname nishizuka; dots@ietf.org
Objet : RE: = [Dots] DOTS Telemetry: Interop Clarification = #1

 

Hi Med,

 

I think that this refers = several places.

 

1.       = Efficacy = updates.  E.g.  Figure 45: An Example of Mitigation Efficacy = Update with Telemetry  Attributes. Here we do an efficacy update of = what the client is seeing happen to a specific resource.  If the = client now does a GET against the same resource – what is returned = – the last efficacy update or the current state of mitigation as = seen by the DOTS server?

 

2.       = Also, = Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows the = client to update the tmid with some information.  This includes an = attack-detail.  When the client wants to see what is happening with = this “tmid”, it does a Figure 40: GET to Subscribe to = Telemetry Asynchronous Notifications for a Specific 'tmid'.  Which = attack-detail is returned – the one from the PUT or the ongoing = situation?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 25 June 2020 = 20:29
To: kaname nishizuka
Cc: = dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop = Clarification #1

 

Hi Kaname, =

 

We discussed = this issue in the interim:

 

=3D=3D

Current = Uri-Path can't distinguish telemetry resources posted by the client or = created by the server.

–Those = are totally different resources.

For example, Uri-Query won't be applicable to the = telemetry resources posted by the client.

=3D=3D

 

Can you please = identify precisely which parts of the text need to be = updated?

 

Thank you =

 

Cheers,

Med

 
____________________________________________________________=
_____________________________________________________________<=
/span>
 
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.
------=_NextPart_000_0B70_01D64E2A.558E7240-- From nobody Mon Jun 29 22:35:24 2020 Return-Path: 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 E1CBB3A0B28 for ; Mon, 29 Jun 2020 22:35:21 -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 67pBJfl8g77b for ; Mon, 29 Jun 2020 22:35:19 -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 28E2C3A0A2C for ; Mon, 29 Jun 2020 22:35:18 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 49wtNj29d8z1yDZ; Tue, 30 Jun 2020 07:35:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593495317; bh=LhC7Anb+VIboi+ECrdEASJvWs1aZg3k0BEMciZBRSR8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=A7tDxHxo5B5/VQIi2qu7UzEd4qpx3AnXCxRlXy27LcelkBHEHBO12E5mxakR7yXf2 Wd+wDDC5/SZ90qxqX6ikxxa1hPBokjKdZOJUaiCn5W+V50SoxmydpuKiSWXRIIRFKO fB8cXdgruOowPCaXseMyolDZvOee6qtZ8jl23n4SgI2UDei5CE4IeaperKNNmmyEPj 0phExXXl2tBOLQc0MyJJ3+dFpup3OP8vFh39NkkhjcZq7ET2CIg0Z3AeaKbYH7UFW3 Bt3Mk4NDoT6UMM5fZWqnNqm8cWWK5gGFLxdeFC8OVKWGjLwiVzEzbfssT6Hcrdek2Z uVy3j1II6da8g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 49wtNj1K0hzDq7B; Tue, 30 Jun 2020 07:35:17 +0200 (CEST) From: To: Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] DOTS Telemetry: Interop Clarification #1 Thread-Index: AQH0NBewyz0cz3gVN6O99zZ2D4scewEFmq9oAkUV0A4B4ImsbALKkiyFARsEWX0BV16v26hgmA9AgAD5CUA= Date: Tue, 30 Jun 2020 05:35:16 +0000 Message-ID: <18547_1593495317_5EFACF15_18547_322_1_787AE7BB302AE849A7480A190F8B9330314E95E8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <25679_1593113350_5EF4FB06_25679_457_1_787AE7BB302AE849A7480A190F8B9330314E762D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <084a01d64bb2$d63a86b0$82af9410$@jpshallow.com> <9226_1593412702_5EF98C5E_9226_29_1_787AE7BB302AE849A7480A190F8B9330314E8989@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ad501d64df5$74b89b30$5e29d190$@jpshallow.com> <16374_1593427492_5EF9C624_16374_188_1_787AE7BB302AE849A7480A190F8B9330314E8BF2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0b1401d64e0a$36c332d0$a4499870$@jpshallow.com> <27502_1593433239_5EF9DC97_27502_120_16_787AE7BB302AE849A7480A190F8B9330314E8CFE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0b6f01d64e21$f3c6d5f0$db5481d0$@jpshallow.com> In-Reply-To: <0b6f01d64e21$f3c6d5f0$db5481d0$@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_787AE7BB302AE849A7480A190F8B9330314E95E8OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 05:35:22 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314E95E8OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, We can't say "will not include any efficacy update information" because the= efficacy update includes also the mitigation scope that is returned by the= server. The server treats the supplied telemetry data as a hint; this is t= he same way it handles "attack-status" from the client. Also, we do have th= e following: DOTS clients can send mitigation hints derived from attack details to DOTS servers, with the full understanding that the DOTS server may ignore mitigation hints Please note that the efficacy update is clearly indicated as a refresh of t= he mitigation request in RFC8782. We can add a reminder if needed. I suspect that what confused you is the use of the same "tmid" in Figure 43= and Figure 36. I changed Figures 39-43 to use a new value "567". Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 29 juin 2020 16:31 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, I think that it is worth adding a note for clarity such as OLD Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notification from the DOTS Server NEW Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notification from the DOTS Server Note: Any information uploaded by a PUT (see Figure 36) will not be include= d in such a response. END and OLD Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes NEW Figure 45: An Example of Mitigation Efficacy Update with Telemetry Attributes Note: Any information retrieved by a GET command for this 'mid' will not in= clude any efficacy update information. END Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 June 2020 13:21 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 29 juin 2020 13:41 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, I'm still confused - could be that we are talking cross purposes here. See inline Jon> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 June 2020 11:45 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Jon, It is the other way around: the server will filter out the data it will ret= urn to match the filters conveyed in GET. Jon> That filtering I agree with. [Med] OK. It just is what is the data source used for the server GET response. So, =B7 if we refer to your case (1), the PUT used for efficacy update = does not interfere with the handling of GET to retrieve the server's status. Jon> Figure 45 PUT includes "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabit-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] Jon> What does the DOTS server respond with for a GET - the value "900 meg= abit-ps" or what the DOTS server (as told by DOTS mitigator etc.) thinks is= actually happening - e.g. "11 gigabit-ps" because a lot of attack traffic = is being dropped by the DOTS mitigators? Just to be absolutely sure - the = server is getting its status from multiple sources - which status does it r= eport on in the GET. [Med] The server will report the status it is seeing (reported from mitigat= ors), not the one inferred from the efficacy update from the client. We are= not changing the behavior we have in the base spec. =B7 if we refer to your case (2), the PUT in Figure 36 sets the tar= get (telemetry) scope. So for any telemetry-related GET, the server will on= ly return data that is bound to the target as set in the PUT. These data is= further filtered out based of any uri-query in the GET. Jon> Figure 36 PUT goes beyond defining the target (alias-name in this case= ) and includes "attack-detail": [ { "vendor-id": 1234, "attack-id": 77, "start-time": "1957811234", "attack-severity": "high" } ] Jon> So what is returned in the GET for this target - this attack detail or= the attack detail that the DOTS server is being told by the DOTS mitigator= s - which could include the same vendor-id + attack-id (but maybe with a di= fferent start time)? [Med] Like above, the status that will be reported is the one from mitigato= rs. ~Jon Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 29 juin 2020 11:13 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, So for absolute clarity, the DOTS server will return the values it has inte= rnally determined (from DOTS mitigator etc.), not those provided by the DOT= S client using a PUT, as modified by the GET Query filters. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 June 2020 07:38 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Jon, all, The server will return the data that match the filters included in the GET = that triggered the response. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 26 juin 2020 14:11 =C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Med, I think that this refers several places. 1. Efficacy updates. E.g. Figure 45: An Example of Mitigation Effic= acy Update with Telemetry Attributes. Here we do an efficacy update of wha= t the client is seeing happen to a specific resource. If the client now do= es a GET against the same resource - what is returned - the last efficacy u= pdate or the current state of mitigation as seen by the DOTS server? 2. Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry a= llows the client to update the tmid with some information. This includes a= n attack-detail. When the client wants to see what is happening with this = "tmid", it does a Figure 40: GET to Subscribe to Telemetry Asynchronous Not= ifications for a Specific 'tmid'. Which attack-detail is returned - the on= e from the PUT or the ongoing situation? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 25 June 2020 20:29 To: kaname nishizuka Cc: dots@ietf.org Subject: [Dots] DOTS Telemetry: Interop Clarification #1 Hi Kaname, We discussed this issue in the interim: =3D=3D Current Uri-Path can't distinguish telemetry resources posted by the client= or created by the server. -Those are totally different resources. For example, Uri-Query won't be applicable to the telemetry resources poste= d by the client. =3D=3D Can you please identify precisely which parts of the text need to be update= d? Thank you Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_787AE7BB302AE849A7480A190F8B9330314E95E8OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

We can’t say “will not include any efficacy update = information” because the efficacy update includes also the mitigation= scope that is returned by the server. The server treats the supplied telemetry data as a hint; this is the same way it handles “attack-st= atus” from the client. Also, we do have the following:

 

   DOTS clients can send mitigation hints derive= d from attack details to

   DOTS servers, with the full understanding tha= t the DOTS server may

   ignore mitigation hints

 

Please note that the efficacy update is clearly indicated as a = refresh of the mitigation request in RFC8782. We can add a reminder if need= ed.  

 

I suspect that what confused you is the use of the same “= tmid” in Figure 43 and Figure 36. I changed Figures 39-43 to use a ne= w value “567”.

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 29 juin 2020 16:31
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

I think= that it is worth adding a note for clarity such as

&n= bsp;

OLD

 &= nbsp;   Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Te= lemetry

 &= nbsp;           &nbs= p;       Notification from the DOTS Server

NEW

 &= nbsp;   Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Te= lemetry

 &= nbsp;           &nbs= p;       Notification from the DOTS Server

&n= bsp;

Note: A= ny information uploaded by a PUT (see Figure 36) will not be included in su= ch a response.

END

&n= bsp;

and

&n= bsp;

OLD

 &= nbsp;  Figure 45: An Example of Mitigation Efficacy Update with Teleme= try

 &= nbsp;           &nbs= p;            &= nbsp;     Attributes

NEW

 &= nbsp;  Figure 45: An Example of Mitigation Efficacy Update with Teleme= try

 &= nbsp;           &nbs= p;            &= nbsp;     Attributes

&n= bsp;

Note: A= ny information retrieved by a GET command for this ‘mid’ will n= ot include any efficacy update information.

END

&n= bsp;

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 June 2020 13:21
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 29 juin 2020 13:41
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.or= g
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

I’= ;m still confused – could be that we are talking cross purposes here.=

&n= bsp;

See inl= ine Jon>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 June 2020 11:45
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Jon,

 

It is the other way around: the server will filter out the data= it will return to match the filters conveyed in GET.

Jon> That filtering= I agree with.

[Med] OK.

  It just is what= is the data source used for the server GET response.

 

So,

=B7         if we refer to your case (1), the PUT used for efficacy= update does not interfere with the handling of GET to retrieve the server&= #8217;s status.

Jon> Figure 45 PUT = includes

           "i= etf-dots-telemetry:total-attack-traffic": [

           &n= bsp; {

           &n= bsp;   "ietf-dots-telemetry:unit": "megabit-ps&quo= t;,

           &n= bsp;   "ietf-dots-telemetry:mid-percentile-g": "90= 0"

           &n= bsp; }

   &nbs= p;       ]

Jon>  What doe= s the DOTS server respond with for a GET – the value “900 megab= it-ps” or what the DOTS server (as told by DOTS mitigator etc.) think= s is actually happening – e.g. “11 gigabit-ps” because a = lot of attack traffic is being dropped by the DOTS mitigators?  Just to be a= bsolutely sure – the server is getting its status from multiple sourc= es – which status does it report on in the GET.

[Med] The server will report the status it is seeing (rep= orted from mitigators), not the one inferred from the efficacy update from = the client. We are not changing the behavior we have in the base spec.

 

=B7         if we refer to your case (2), the PUT in Figure 36 sets= the target (telemetry) scope. So for any telemetry-related GET, the server= will only return data that is bound to the target as set in the PUT. These data is further filtered out based of any = uri-query in the GET.

Jon> Figure 36 PUT = goes beyond defining the target (alias-name in this case) and includes=

           "a= ttack-detail": [

           &n= bsp; {

           &n= bsp;   "vendor-id": 1234,

           &n= bsp;   "attack-id": 77,

           &n= bsp;   "start-time": "1957811234",=

           &n= bsp;   "attack-severity": "high"

           &n= bsp; }

   &nbs= p;       ]

Jon> So what is ret= urned in the GET for this target – this attack detail or the attack d= etail that the DOTS server is being told by the DOTS mitigators – whi= ch could include the same vendor-id + attack-id (but maybe with a different start time)?

[Med] Like above, the status that will be reported is the= one from mitigators.   

 

~Jon   

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 29 juin 2020 11:13
=C0 : BOUCADAIR Mohamed TGI/OLN;= kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

So for = absolute clarity, the DOTS server will return the values it has internally = determined (from DOTS mitigator etc.), not those provided by the DOTS clien= t using a PUT, as modified by the GET Query filters.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 June 2020 07:38
To: Jon Shallow; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Jon, all,

 

The server will return the data that match the filters includ= ed in the GET that triggered the response.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 26 juin 2020 14:11
=C0 : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; dots@ietf.or= g
Objet : RE: [Dots] DOTS Telemetry: Interop Clarification #1

 

Hi Med,=

&n= bsp;

I think= that this refers several places.

&n= bsp;

1.       Efficacy updates.  E.g.  Figure 45: An Example of Mitigation Eff= icacy Update with Telemetry  Attributes. Here we do an efficacy update= of what the client is seeing happen to a specific resource.  If the client now does a GET against the same resource = 211; what is returned – the last efficacy update or the current state= of mitigation as seen by the DOTS server?

&n= bsp;

2.       Also, Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry allows th= e client to update the tmid with some information.  This includes an a= ttack-detail.  When the client wants to see what is happening with this “tmid”, it does a Figure 40: GET t= o Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'.&= nbsp; Which attack-detail is returned – the one from the PUT or the o= ngoing situation?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 25 June 2020 20:29
To: kaname nishizuka
Cc: dots@ietf.org
Subject: [Dots] DOTS Telemetry: Interop Clarification #1<= /span>

 

Hi Kaname,

 

= We discussed this issue in the interim:

=  

= =3D=3D

= Current Uri-Path can't distinguish telemetry resources posted by the client= or created by the server.

= –Those are totally different resources.

= For example, Uri-Query won't be applicable to the telemetry resources poste= d by the client.

= =3D=3D

=  

= Can you please identify precisely which parts of the text need to be update= d?

=  

= Thank you

=  

= Cheers,

Med

 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_787AE7BB302AE849A7480A190F8B9330314E95E8OPEXCAUBMA2corp_-- From nobody Tue Jun 30 08:43:01 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7FB3A0B57; Tue, 30 Jun 2020 08:42:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jan Lindblad via Datatracker To: Cc: dots@ietf.org, draft-ietf-dots-telemetry.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159353177839.29172.8254735147639701580@ietfa.amsl.com> Reply-To: Jan Lindblad Date: Tue, 30 Jun 2020 08:42:58 -0700 Archived-At: Subject: [Dots] Yangdoctors early review of draft-ietf-dots-telemetry-09 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 15:42:59 -0000 Reviewer: Jan Lindblad Review result: Not Ready This is the YD early review of draft-ietf-dots-telemetry as requested by the DOTS WG. The ietf-dots-telemetry YANG module is not like other YANG modules. It specifically states that it does not pertain to NETCONF/RESTCONF management, but is only meant to be mapped to a specific CoAP based protocol "dots-signal-channel" created by the DOTS WG. The draft-ietf-dots-telemetry says in section 4.7: The DOTS telemetry module (Section 9.1) is not intended to be used via NETCONF/RESTCONF for DOTS server management purposes. It serves only to provide a data model and encoding, but not a management data model. DOTS servers are allowed to update the non-configurable 'ro' entities in the responses of DOTS telemetry messages. While this approach is highly uncommon, after giving it some thought, I believe this approach could be useful to client and server implementors. However, I find two fundamental problems in the particular way this has been done in this case. I believe the problems are fixable, but may involve updating existing DOTS RFCs. #1) YANG data declarations used as message bodies You can define your own message types with whatever content you desire in YANG. Just use rpc/action and notification statements. This draft does not do that, but instead defines message bodies as if they were top level YANG config elements. This obviously violates the aras of YANG that speak about data stores, accessible data trees, and what not. Apart from confusing experienced YANG users, the meaning of statements like "config false" is suddenly most unclear when the foundations of YANG are disregarded. In my opinion the top level of the module needs to be rewritten to use proper YANG rpc/action and notification statements. The existing message bodies, and the way they are augmented, could all work very well. It's just the framework around them that isn't sound. Unfortunately the problematic top level structures of draft-ietf-dots-telemetry are based on structures imported from ietf-dots-signal-channel.yang, which is already published in DOTS RFC 8782. I have not been able to find any YD review of this module, so I would suspect none were ever performed. To make the DOTS signal-channel framework usable, I would suggest obsoleting RFC8782 and write a bis with an improved YANG action/notification based foundation. The number of changed lines in the YANG can probably be kept rather small. #2) Missing pieces in YANG to dots-signal-channel protocol mapping The draft-ietf-dots-telemetry references CoAP RFC 7959, which defines a number of basic management operations (GET, PUT, POST, ...), and CBOR RFC 7049 content encoding, with the draft-ietf-core-yang-cbor-12 addendum for how YANG data is to be encoded in CBOR. Unfortunately, a protocol specification that consists of these three references is not quite complete. Since this is an early review, it may be that the draft authors are already planning to pull the protocol specification up a notch, or I may have missed some piece(s) of the puzzle. In any case, a protocol specification on par with what is available for RESTCONF or NETCONF would be required. The dots-signal-channel specification in RFC 8782 makes an Informative Reference to draft specification for a protocol called CoMI (draft-ietf-core-comi-09), which attempts to take on the YANG to CoAP mapping. One way of filling in the blanks for dots-signal-channel might be to leverage the CoMI work. Fixing #1 would be required to leverage CoMI. Currently, dots-signal-channel protocol specification (taken as the sum of CoAP, CBOR and draft-ietf-core-yang-cbor-12) is missing information about operation semantics, operation encoding, error handling, for example. RFC 8040 sections 5, 6, 7 or RFC 6241 sections 4, 7, 8 contain the sort of information I'm looking for. #3) Other than that, probably good Other than issues #1 and #2 above, the module seems to be in pretty good shape. Some content is hard to judge since the intended meaning of config true/false for example is unclear, so a new review will be required after the fundamentals have been resolved. The module is both easy to read and conforms with IETF standards except as noted above, staying on the clean and simple side. From nobody Tue Jun 30 23:41:16 2020 Return-Path: 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 4D8AB3A085F; Tue, 30 Jun 2020 23:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 cBkE5yV1ddF1; Tue, 30 Jun 2020 23:41:12 -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 253D03A0848; Tue, 30 Jun 2020 23:41:12 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 49xWpG25MyzyhH; Wed, 1 Jul 2020 08:41:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593585670; bh=+DCsvSNntLSgclWnnjyh9ayFvBM6jMiMJuHHD+f3k40=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=xmrcIusj/PeA59CQXUi0d6nlR9Pm6bL+Foos2YOMYoHmmemQqhaQUKTuALvtWlJr/ pFNbDhdrO67eeX2qagHeH++CgVMMOdpPk9Kwwwc7kuCAPjjrpCjwO9B7iMSULf1XAa 2h1QZHdcOO6J/W6zFsw2hjHvCR/rdY6LeBdaCj8bhv4enJ5676tWNyeqmfYaixOvsE 1kqsrvrDDDLER0TmSCBLNGxcSRGySC5XsFVFDFII9sEDlMb1cvBYWPNFW6E4nm6Cqb a9O//eY7VhhfnhTbiOwY/r1Aqi+Z/51xDNQwFziKMLvRN0VEGbJERLZ+pOrlSoi+qO b2X2dVaIasa1w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 49xWpG1HDnzDq7P; Wed, 1 Jul 2020 08:41:10 +0200 (CEST) From: To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= , "janl@tail-f.com" CC: "yang-doctors@ietf.org" , "draft-ietf-dots-telemetry.all@ietf.org" , "dots@ietf.org" Thread-Topic: [yang-doctors] Yangdoctors early review of draft-ietf-dots-telemetry-09 Thread-Index: AQHWTwrcyLUzg4toRReM83kxwr9eLajyRxUw Date: Wed, 1 Jul 2020 06:41:09 +0000 Message-ID: <20313_1593585670_5EFC3006_20313_116_1_787AE7BB302AE849A7480A190F8B9330314EA69B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159353177839.29172.8254735147639701580@ietfa.amsl.com> <20200630.201818.699105283686964442.id@4668.se> In-Reply-To: <20200630.201818.699105283686964442.id@4668.se> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [yang-doctors] Yangdoctors early review of draft-ietf-dots-telemetry-09 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 06:41:14 -0000 Hi Jan, Martin,=20 Thank you for the review.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De : Martin Bj=F6rklund [mailto:mbj+ietf@4668.se] > Envoy=E9 : mardi 30 juin 2020 20:18 > =C0 : janl@tail-f.com; noreply@ietf.org > Cc : yang-doctors@ietf.org; draft-ietf-dots-telemetry.all@ietf.org; > dots@ietf.org > Objet : Re: [yang-doctors] Yangdoctors early review of draft-ietf-dots- > telemetry-09 >=20 > Hi, >=20 > Jan Lindblad via Datatracker wrote: > > Reviewer: Jan Lindblad > > Review result: Not Ready > > > > This is the YD early review of draft-ietf-dots-telemetry as requested by > the > > DOTS WG. > > > > The ietf-dots-telemetry YANG module is not like other YANG modules. It > > specifically states that it does not pertain to NETCONF/RESTCONF > management, > > but is only meant to be mapped to a specific CoAP based protocol > > "dots-signal-channel" created by the DOTS WG. The draft-ietf-dots- > telemetry > > says in section 4.7: > > > > The DOTS telemetry module (Section 9.1) is not intended to be used > > via NETCONF/RESTCONF for DOTS server management purposes. It serves > > only to provide a data model and encoding, but not a management data > > model. DOTS servers are allowed to update the non-configurable 'ro' > > entities in the responses of DOTS telemetry messages. > > [Med] I confirm. We are using YANG for structuring the data that will be ex= changed between the client and the server. We may think about this as some = sort of service model as per RFC8309. > > While this approach is highly uncommon, after giving it some thought, I > believe > > this approach could be useful to client and server implementors. Howeve= r, > I > > find two fundamental problems in the particular way this has been done = in > this > > case. I believe the problems are fixable, but may involve updating > existing > > DOTS RFCs. > > > > #1) YANG data declarations used as message bodies > > > > You can define your own message types with whatever content you desire = in > YANG. > > Just use rpc/action and notification statements. >=20 > You may also want to look at RFC 8791, which defines a new YANG > extension statement "sx:structure". This statement can be used to > define messages that are not intended to be generic rpcs or > notifications. >=20 >=20 [Med] Thanks for the pointer, Martin.=20=20 Importing ietf-yang-structure-ext + s/container dots-signal/sx:structure in= ietf-dots-signal-channel (RFC8782) would be sufficient to define the struc= ture as per RFC8791 but we will lose the "tagging" of parts of the structur= e/schema that applies only in the server to client direction. We used rw/ro so that we can have a compact module/structure that can be us= ed in both directions of the DOTS communication, rather than defining two s= tructures.=20=20 The good news is that with both the current approach in RFC8782 and an upda= ted one that strictly follows RFC 8791, we will have the same JSON/CBOR map= pings that are authoritative for our spec (Section 6 of RFC8782).=20 Given that we don't have interoperability issues, would it be OK with you i= f we update draft-ietf-dots-telemetry to add a reference to inform the read= er about RFC8791 and that we are not using it here because we are augmentin= g a module not using sx:structure?=20 If there is any RFC8782bis in the future, making changes to follow RFC8791 = will be part of the things to be considered.=20=20=20 >=20 > > This draft does not do that, > > but instead defines message bodies as if they were top level YANG config > > elements. This obviously violates the aras of YANG that speak about data > > stores, accessible data trees, and what not. Apart from confusing > experienced > > YANG users, the meaning of statements like "config false" is suddenly > most > > unclear when the foundations of YANG are disregarded. > > > > In my opinion the top level of the module needs to be rewritten to use > proper > > YANG rpc/action and notification statements. The existing message bodie= s, > and > > the way they are augmented, could all work very well. It's just the > framework > > around them that isn't sound. > > > > Unfortunately the problematic top level structures of draft-ietf-dots- > telemetry > > are based on structures imported from ietf-dots-signal-channel.yang, > which is > > already published in DOTS RFC 8782. I have not been able to find any YD > review > > of this module, so I would suspect none were ever performed. To make the > DOTS > > signal-channel framework usable, I would suggest obsoleting RFC8782 and > write a > > bis with an improved YANG action/notification based foundation. The > number of > > changed lines in the YANG can probably be kept rather small. > > > > #2) Missing pieces in YANG to dots-signal-channel protocol mapping > > [Med] What is key for the mapping is listed in draft-ietf-dots-telemetry-09= #section-10. All the foundations are already specified in RFC8782. Section = 3 of that RFC describes the rationale.=20 > > The draft-ietf-dots-telemetry references CoAP RFC 7959, which defines a > number > > of basic management operations (GET, PUT, POST, ...), and CBOR RFC 7049 > content > > encoding, with the draft-ietf-core-yang-cbor-12 addendum for how YANG > data is > > to be encoded in CBOR. Unfortunately, a protocol specification that > consists of > > these three references is not quite complete. Since this is an early > review, it > > may be that the draft authors are already planning to pull the protocol > > specification up a notch, or I may have missed some piece(s) of the > puzzle. In > > any case, a protocol specification on par with what is available for > RESTCONF > > or NETCONF would be required. > > > > The dots-signal-channel specification in RFC 8782 makes an Informative > > Reference to draft specification for a protocol called CoMI > > (draft-ietf-core-comi-09), which attempts to take on the YANG to CoAP > mapping. > > One way of filling in the blanks for dots-signal-channel might be to > leverage > > the CoMI work. Fixing #1 would be required to leverage CoMI. > > > > Currently, dots-signal-channel protocol specification (taken as the sum > of > > CoAP, CBOR and draft-ietf-core-yang-cbor-12) is missing information abo= ut > > operation semantics, operation encoding, error handling, for example. [Med] Such details are discussed in the base CoAP spec, RFC8782, and error = handling specifics are included in this draft.=20=20=20=20 RFC > 8040 > > sections 5, 6, 7 or RFC 6241 sections 4, 7, 8 contain the sort of > information > > I'm looking for. > > > > #3) Other than that, probably good > > > > Other than issues #1 and #2 above, the module seems to be in pretty good > shape. > > Some content is hard to judge since the intended meaning of config > true/false [Med] "config false" is used to tag nodes that must not appear in messages = sent from the client to the server. > > for example is unclear, so a new review will be required after the > fundamentals > > have been resolved. The module is both easy to read and conforms with > IETF > > standards except as noted above, staying on the clean and simple side. > > [Med] Thanks. FWIW, we fixed some issues in the examples. The latest versio= n of the spec is available at: https://github.com/boucadair/draft-dots-tele= metry. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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.