From nobody Thu Apr 2 22:53:51 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 826073A1018 for ; Thu, 2 Apr 2020 22:53:49 -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, UNPARSEABLE_RELAY=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 p22nybqsSo0I for ; Thu, 2 Apr 2020 22:53:44 -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 ED45B3A1016 for ; Thu, 2 Apr 2020 22:53:43 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 48tpyY6wmDz1yJ1; Fri, 3 Apr 2020 07:53:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585893222; bh=XRgdjYyQKKvtmlru0bRifFKpMooV5RXPi9aou4hfiTI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FSP7XaSA0fDn9ACmV6Y4rxJm25r3xbh0cLmlxnLlz0pXMa2WonLp44yZBiRkuGyhF iv2XerCvBse2HXcjehf+nlWmZ8EpyY+Ct0Y7ZMh8NeXpyPhwtmIfZaVHdZupBrnEg8 ifhoeN6LtaMLNSXzrC6y3NZl9XGeTMkmo0PwnDqXkhXksI9TH9X8s21BhfyYjZJx1m 2Zpa1INazHZkwCZnGEqRNdkINcMQHnm5cNRIUO8KesPk76DUyHw7ePfxe+BQjqbYFl 4tmshh2KNKHr7rw9fTkNigs2grygGy/UgCggmyEXUjfijrDkvGVJaCCeUIYwSqpOxh 0UtaYoB6TyGAA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48tpyY6By7z8sYj; Fri, 3 Apr 2020 07:53:41 +0200 (CEST) From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka CC: "dots@ietf.org" Thread-Topic: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AQKpDKSlae91Qx1rveAaG4y93fawwwGS0CN0ActngzYBop/8/AGLlQYiAqtlZCwC5xXv2wJXxJ8rAWqlVlgB+pAcCQK0mLlyAOa0qGymFG2a0IAAsLmg Date: Fri, 3 Apr 2020 05:53:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148D4EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158532456961.24330.9684049527965442282@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303148203F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0acd01d60458$9df439f0$d9dcadd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031482353@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0b7501d604f9$40fd53c0$c2f7fb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031483683@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0db001d606d0$3f6312b0$be293810$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031489524@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ed901d6079d$ad34b1e0$079e15a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148B373@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <101201d60868$affd91a0$0ff8b4e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148D091@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <112b01d60927$b2ae7300$180b5900$@jpshallow.com> In-Reply-To: <112b01d60927$b2ae7300$180b5900$@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 05:53:50 -0000 SGkgSm9uLCANCg0KTW92aW5nIHRoZSBkaXNjdXNzaW9uIHRvIHRoZSBXRyBsaXN0IGFzIHRoaXMg aXMgYW4gaW1wb3J0YW50IGRlc2lnbiBjaGFuZ2Ugd2UgbmVlZCB0byBtYWtlLiANCg0KUGxlYXNl IHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCj4gRGXCoDogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cu Y29tXQ0KPiBFbnZvecOpwqA6IGpldWRpIDIgYXZyaWwgMjAyMCAyMTo0OQ0KPiDDgMKgOiBCT1VD QURBSVIgTW9oYW1lZCBUR0kvT0xOOyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBrYW5hbWUN Cj4gbmlzaGl6dWthDQo+IE9iamV0wqA6IFJFOiBbRG90c10gTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLWRvdHMtDQo+IHRlbGVtZXRyeS0wNS50eHQNCj4gDQo+IFN0ZXBw aW5nIGJhY2sgdG8gbG9vayBhdCB0aGUgYmlnZ2VyIHBpY3R1cmUsIEkgdGhpbmsgdGhhdCBJIHdv dWxkIGJlDQo+IG1vcmUgaW50ZXJlc3RlZCBpbiB0aGUgZGV0YWlsIG9mIGEgcG90ZW50aWFsbHkg bXVsdGktdmVjdG9yZWQgbXV0YXRpbmcNCj4gYXR0YWNrLCBhbmQgc28gcXVlc3Rpb24gd2hldGhl ciBoYXZpbmcgdGFyZ2V0LXByb3RvY29sIGFzIGFuIG92ZXJhbGwNCj4gcmVzdHJpY3RpdmUgdmll dyBvZiBhbGwgdGhlIGRldGFpbCBtYWtlcyBzZW5zZS4gIEl0IGlzIGVhc2llciB0bw0KPiBmaWx0 ZXIgb3V0IGRhdGEgdGhhdCBJIGRvIG5vdCB3YW50IC8gY2FyZSBhYm91dCBhZnRlciByZWNlaXZp bmcgaXQuDQo+IFRoZSByZW1vdGUgcGVlciBtYXkgbm90IGhhdmUgdGhlIHNhbWUgdmlldyBvZiB3 aGF0IHRvIHNlbmQgdiB3aGF0IEkgYW0NCj4gaW50ZXJlc3RlZCBpbi4NCj4gDQo+IFtJIGFtIGNv bmNlcm5lZCBhYm91dCBvdmVyLWZpbGxpbmcgYSBwYWNrZXQgYW5kIGhhdmluZyB0byBnbyBpbnRv IENvQVANCj4gQmxvY2syIG1vZGUgdGhvdWdoIHdoaWNoIHdpbGwgZmFpbCBvbiBhIHNhdHVyYXRl ZCBsaW5rLiAgSSBoYXZlIG5vdA0KPiBkb25lIGFueSBzaXppbmcgb2YgdGhhdCB5ZXQgd2l0aCBn ZW51aW5lIGF0dGFjayBpbmZvcm1hdGlvbl0NCj4gDQo+IFNvLCBmb3IgdGhlIC90bSBhbmQgL3Rt LXNldHVwIHN0dWZmIGRvIHdlIHJlYWxseSBuZWVkIHRhcmdldC1wcm90b2NvbA0KPiBhbmQgY291 bGQganVzdCBoYXZlIHByb3RvY29sIGFzIGFuIG9wdGlvbmFsLCBidXQgYXJyYXksIGVudGl0eT8N Cg0KW01lZF0gSXQgaXMgaW1wb3J0YW50IHRvIHByb3ZpZGUgZGV0YWlscyBwZXIgcHJvdG9jb2wg YXMgdGhpcyB3aWxsIGhlbHAgaWRlbnRpZnlpbmcgYWJub3JtYWwgcGF0dGVybnMuIA0KDQpXZSBj b3VsZCBhc3NvY2lhdGUgMCB0byBtZWFuICJhbGwiIHByb3RvY29scyBidXQgSSBrbm93IHRoaXMg d2lsbCBodXJ0IG1hbnkuIFdlIGNhbiBjb25zaWRlciB0aGUgZm9sbG93aW5nIGNoYW5nZToNCg0K T0xEDQoNCiAgICB8ICAgICAgICAgICArLS1ydyBiYXNlbGluZSogW2lkXQ0KICAgIHwgICAgICAg ICAgICAgICstLXJ3IGlkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMg0KICAg IHwgICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcmVmaXgqICAgICAgICAgICAgICAgICAgIGlu ZXQ6aXAtcHJlZml4DQogICAgfCAgICAgICAgICAgICAgKy0tcncgdGFyZ2V0LXBvcnQtcmFuZ2Uq IFtsb3dlci1wb3J0XQ0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGxvd2VyLXBvcnQgICAg aW5ldDpwb3J0LW51bWJlcg0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHVwcGVyLXBvcnQ/ ICAgaW5ldDpwb3J0LW51bWJlcg0KICAgIHwgICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcm90 b2NvbCogICAgICAgICAgICAgICAgIHVpbnQ4DQogICAgfCAgICAgICAgICAgICAgKy0tcncgdGFy Z2V0LWZxZG4qICAgICAgICAgICAgICAgICAgICAgaW5ldDpkb21haW4tbmFtZQ0KICAgIHwgICAg ICAgICAgICAgICstLXJ3IHRhcmdldC11cmkqICAgICAgICAgICAgICAgICAgICAgIGluZXQ6dXJp DQogICAgfCAgICAgICAgICAgICAgKy0tcncgdG90YWwtdHJhZmZpYy1ub3JtYWwtYmFzZWxpbmUq IFt1bml0IHByb3RvY29sXQ0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHVuaXQgICAgICAg ICAgICAgICAgIHVuaXQNCiAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyBwcm90b2NvbCAgICAg ICAgICAgICB1aW50OA0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGxvdy1wZXJjZW50aWxl LWc/ICAgIHlhbmc6Z2F1Z2U2NA0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IG1pZC1wZXJj ZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGhp Z2gtcGVyY2VudGlsZS1nPyAgIHlhbmc6Z2F1Z2U2NA0KICAgIHwgICAgICAgICAgICAgIHwgICst LXJ3IHBlYWstZz8gICAgICAgICAgICAgIHlhbmc6Z2F1Z2U2NA0KDQpORVc6DQoNCiAgICB8ICAg ICAgICArLS06KGJhc2VsaW5lKQ0KICAgIHwgICAgICAgICAgICstLXJ3IGJhc2VsaW5lKiBbaWRd DQogICAgfCAgICAgICAgICAgICAgKy0tcncgaWQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHVpbnQzMg0KICAgIHwgICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcmVmaXgqICAg ICAgICAgICAgICAgICAgICAgICBpbmV0OmlwLXByZWZpeA0KICAgIHwgICAgICAgICAgICAgICst LXJ3IHRhcmdldC1wb3J0LXJhbmdlKiBbbG93ZXItcG9ydF0NCiAgICB8ICAgICAgICAgICAgICB8 ICArLS1ydyBsb3dlci1wb3J0ICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICB8ICAgICAgICAgICAg ICB8ICArLS1ydyB1cHBlci1wb3J0PyAgIGluZXQ6cG9ydC1udW1iZXINCiAgICB8ICAgICAgICAg ICAgICArLS1ydyB0YXJnZXQtcHJvdG9jb2wqICAgICAgICAgICAgICAgICAgICAgdWludDgNCiAg ICB8ICAgICAgICAgICAgICArLS1ydyB0YXJnZXQtZnFkbiogICAgICAgICAgICAgICAgICAgICAg ICAgaW5ldDpkb21haW4tbmFtZQ0KICAgIHwgICAgICAgICAgICAgICstLXJ3IHRhcmdldC11cmkq ICAgICAgICAgICAgICAgICAgICAgICAgICBpbmV0OnVyaQ0KICAgIHwgICAgICAgICAgICAgICst LXJ3IGFsaWFzLW5hbWUqICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCiAgICB8ICAg ICAgICAgICAgICArLS1ydyB0b3RhbC10cmFmZmljLW5vcm1hbCogW3VuaXRdDQogICAgfCAgICAg ICAgICAgICAgfCAgKy0tcncgdW5pdCAgICAgICAgICAgICAgICAgdW5pdA0KICAgIHwgICAgICAg ICAgICAgIHwgICstLXJ3IGxvdy1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KICAgIHwg ICAgICAgICAgICAgIHwgICstLXJ3IG1pZC1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0K ICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGhpZ2gtcGVyY2VudGlsZS1nPyAgIHlhbmc6Z2F1 Z2U2NA0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHBlYWstZz8gICAgICAgICAgICAgIHlh bmc6Z2F1Z2U2NA0KICAgIHwgICAgICAgICAgICAgICstLXJ3IHRvdGFsLXRyYWZmaWMtbm9ybWFs LXBlci1wcm90b2NvbCogW3VuaXQgcHJvdG9jb2xdDQogICAgfCAgICAgICAgICAgICAgfCAgKy0t cncgdW5pdCAgICAgICAgICAgICAgICAgdW5pdA0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3 IHByb3RvY29sICAgICAgICAgICAgIHVpbnQ4DQogICAgfCAgICAgICAgICAgICAgfCAgKy0tcncg bG93LXBlcmNlbnRpbGUtZz8gICAgeWFuZzpnYXVnZTY0DQogICAgfCAgICAgICAgICAgICAgfCAg Ky0tcncgbWlkLXBlcmNlbnRpbGUtZz8gICAgeWFuZzpnYXVnZTY0DQogICAgfCAgICAgICAgICAg ICAgfCAgKy0tcncgaGlnaC1wZXJjZW50aWxlLWc/ICAgeWFuZzpnYXVnZTY0DQogICAgfCAgICAg ICAgICAgICAgfCAgKy0tcncgcGVhay1nPyAgICAgICAgICAgICAgeWFuZzpnYXVnZTY0DQoNCk9m IGNvdXJzZSwgdGhlIHByb3RvY29sIG11c3QgYmUgbGlzdGVkIGluIHRhcmdldC1wcm90b2NvbCAo aWYgcHJlc2VudCkuDQoNCj4gDQo+IFRoZW4gZm9yIC9taXRpZ2F0ZSwgdGFyZ2V0LXByb3RvY29s IGlzIGlnbm9yZWQgaW4gZGVjaWRpbmcgd2hhdCB0bw0KPiBzZW5kIGJhY2ssIGJ1dCB0aGUgdXNl IG9mIGFuIG9wdGlvbmFsIHByb3RvY29sIGFycmF5IGNhbiByZWR1Y2Ugc29tZQ0KPiBvZiB0aGUg cGFja2V0IHNpemUuDQo+IA0KPiB0b3RhbC1hdHRhY2stY29ubmVjdGlvbiAgLyB0b3RhbC1jb25u ZWN0aW9uLWNhcGFjaXR5IHdpbGwgb25seSBiZSBmb3INCj4gY29ubmVjdGlvbiBiYXNlZCBjb25u ZWN0aW9ucyAtIHByaW1hcmlseSBUQ1AgSSBzdXNwZWN0LiANCg0KW01lZF0gQWdyZWUuDQoNCiBI b3dldmVyDQo+ICh0YXJnZXQpIHBvcnRzIG1heSBiZSByZWxldmFudCBoZXJlIC0gYSBzZXJ2ZXIg bWF5IGJlIGFibGUgdG8gc3VwcG9ydA0KPiBYIEhUVFBTIGNvbm5lY3Rpb25zLCBidXQgb25seSBZ IEROUyAoVENQKSBjb25uZWN0aW9ucyAtIG9yIGEgbG9hZC0NCj4gYmFsYW5jZXIgaW4gdGhlIHBh dGggaXMgb25seSAgY2FwYWJsZSBvZiBoYW5kbGluZyBaIGNvbm5lY3Rpb25zIC0gbm8NCj4gbWF0 dGVyIHdoYXQgdGhlIHBvcnQgaXMuLiAgU28sIGRvIHdlIHdhbnQgdG8gaW50cm9kdWNlIG9wdGlv bmFsIHBvcnRzPw0KDQpbTWVkXSBUaGVzZSBwb3J0cyBoYXZlIHRvIGJlIGxpc3RlZCBpbiB0YXJn ZXQtcG9ydC1yYW5nZSAoaWYgcHJlc2VudCkuIElmIHdlIGluY2x1ZGUgcG9ydCB0byB0aGUgZXhp c3RpbmcgbGlzdCwgd2UgY2FuJ3QgbWFpbnRhaW4gdHdvIGVudHJpZXMgZm9yIHRoZSBzYW1lIHBy b3RvY29sIGJ1dCB3aXRoIGRpc3RpbmN0IHBvcnQuIEl0IG1heSBiZSBtb3JlIHNpbXBsZSB0byBt YWtlIHRoaXMgY2hhbmdlOg0KDQpPTEQ6DQogICAgfCAgICAgICAgICAgICAgKy0tcncgdG90YWwt Y29ubmVjdGlvbi1jYXBhY2l0eSogW3Byb3RvY29sXQ0KICAgIHwgICAgICAgICAgICAgICAgICst LXJ3IHByb3RvY29sICAgICAgICAgICAgICAgICAgICAgdWludDgNCiAgICB8ICAgICAgICAgICAg ICAgICArLS1ydyBjb25uZWN0aW9uPyAgICAgICAgICAgICAgICAgIHVpbnQ2NA0KICAgIHwgICAg ICAgICAgICAgICAgICstLXJ3IGNvbm5lY3Rpb24tY2xpZW50PyAgICAgICAgICAgdWludDY0DQog ICAgfCAgICAgICAgICAgICAgICAgKy0tcncgZW1icnlvbmljPyAgICAgICAgICAgICAgICAgICB1 aW50NjQNCiAgICB8ICAgICAgICAgICAgICAgICArLS1ydyBlbWJyeW9uaWMtY2xpZW50PyAgICAg ICAgICAgIHVpbnQ2NA0KICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IGNvbm5lY3Rpb24tcHM/ ICAgICAgICAgICAgICAgdWludDY0DQogICAgfCAgICAgICAgICAgICAgICAgKy0tcncgY29ubmVj dGlvbi1jbGllbnQtcHM/ICAgICAgICB1aW50NjQNCiAgICB8ICAgICAgICAgICAgICAgICArLS1y dyByZXF1ZXN0LXBzPyAgICAgICAgICAgICAgICAgIHVpbnQ2NA0KICAgIHwgICAgICAgICAgICAg ICAgICstLXJ3IHJlcXVlc3QtY2xpZW50LXBzPyAgICAgICAgICAgdWludDY0DQogICAgfCAgICAg ICAgICAgICAgICAgKy0tcncgcGFydGlhbC1yZXF1ZXN0LXBzPyAgICAgICAgICB1aW50NjQNCiAg ICB8ICAgICAgICAgICAgICAgICArLS1ydyBwYXJ0aWFsLXJlcXVlc3QtY2xpZW50LXBzPyAgIHVp bnQ2NA0KDQpORVc6DQoNCiAgICB8ICAgICAgICAgICAgICArLS1ydyB0b3RhbC1jb25uZWN0aW9u LWNhcGFjaXR5KiBbcHJvdG9jb2xdDQogICAgfCAgICAgICAgICAgICAgfCAgKy0tcncgcHJvdG9j b2wgICAgICAgICAgICAgICAgICAgICB1aW50OA0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3 IGNvbm5lY3Rpb24/ICAgICAgICAgICAgICAgICAgdWludDY0DQogICAgfCAgICAgICAgICAgICAg fCAgKy0tcncgY29ubmVjdGlvbi1jbGllbnQ/ICAgICAgICAgICB1aW50NjQNCiAgICB8ICAgICAg ICAgICAgICB8ICArLS1ydyBlbWJyeW9uaWM/ICAgICAgICAgICAgICAgICAgIHVpbnQ2NA0KICAg IHwgICAgICAgICAgICAgIHwgICstLXJ3IGVtYnJ5b25pYy1jbGllbnQ/ICAgICAgICAgICAgdWlu dDY0DQogICAgfCAgICAgICAgICAgICAgfCAgKy0tcncgY29ubmVjdGlvbi1wcz8gICAgICAgICAg ICAgICB1aW50NjQNCiAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyBjb25uZWN0aW9uLWNsaWVu dC1wcz8gICAgICAgIHVpbnQ2NA0KICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHJlcXVlc3Qt cHM/ICAgICAgICAgICAgICAgICAgdWludDY0DQogICAgfCAgICAgICAgICAgICAgfCAgKy0tcncg cmVxdWVzdC1jbGllbnQtcHM/ICAgICAgICAgICB1aW50NjQNCiAgICB8ICAgICAgICAgICAgICB8 ICArLS1ydyBwYXJ0aWFsLXJlcXVlc3QtcHM/ICAgICAgICAgIHVpbnQ2NA0KICAgIHwgICAgICAg ICAgICAgIHwgICstLXJ3IHBhcnRpYWwtcmVxdWVzdC1jbGllbnQtcHM/ICAgdWludDY0DQogICAg fCAgICAgICAgICAgICAgKy0tcncgdG90YWwtY29ubmVjdGlvbi1jYXBhY2l0eS1wZXItcG9ydCog W3Byb3RvY29sIGxvd2VyLXBvcnRdDQogICAgfCAgICAgICAgICAgICAgICAgKy0tcncgcHJvdG9j b2wgICAgICAgICAgICAgICAgICAgICB1aW50OA0KICAgIHwgICAgICAgICAgICAgICAgICstLXJ3 IGxvd2VyLXBvcnQgICAgICAgICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgIHwgICAg ICAgICAgICAgICAgICstLXJ3IGNvbm5lY3Rpb24/ICAgICAgICAgICAgICAgICAgdWludDY0DQog ICAgfCAgICAgICAgICAgICAgICAgKy0tcncgY29ubmVjdGlvbi1jbGllbnQ/ICAgICAgICAgICB1 aW50NjQNCiAgICB8ICAgICAgICAgICAgICAgICArLS1ydyBlbWJyeW9uaWM/ICAgICAgICAgICAg ICAgICAgIHVpbnQ2NA0KICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IGVtYnJ5b25pYy1jbGll bnQ/ICAgICAgICAgICAgdWludDY0DQogICAgfCAgICAgICAgICAgICAgICAgKy0tcncgY29ubmVj dGlvbi1wcz8gICAgICAgICAgICAgICB1aW50NjQNCiAgICB8ICAgICAgICAgICAgICAgICArLS1y dyBjb25uZWN0aW9uLWNsaWVudC1wcz8gICAgICAgIHVpbnQ2NA0KICAgIHwgICAgICAgICAgICAg ICAgICstLXJ3IHJlcXVlc3QtcHM/ICAgICAgICAgICAgICAgICAgdWludDY0DQogICAgfCAgICAg ICAgICAgICAgICAgKy0tcncgcmVxdWVzdC1jbGllbnQtcHM/ICAgICAgICAgICB1aW50NjQNCiAg ICB8ICAgICAgICAgICAgICAgICArLS1ydyBwYXJ0aWFsLXJlcXVlc3QtcHM/ICAgICAgICAgIHVp bnQ2NA0KICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IHBhcnRpYWwtcmVxdWVzdC1jbGllbnQt cHM/ICAgdWludDY0DQoNCj4gDQo+ID4gPiBORVc6DQo+ID4gPiAiU2VuZGluZyBhIERFTEVURSB3 aXRoIG5vICd0bWlkJyBpbmRpY2F0ZXMgdGhhdCBhbGwgJ3RtaWRzJyBtdXN0DQo+IGJlDQo+ID4g PiBkZWFjdGl2YXRlZC4iDQo+ID4gPg0KPiANCj4gSSBmb3VuZCB0aGlzIChidXQgSSBwcmVmZXIg eW91ciBhZGRpdGlvbiBmb3IgY29uc2lzdGVuY3kpDQo+IA0KPiAgICBBIERPVFMgY2xpZW50IHRo YXQgbG9zdCB0aGUgc3RhdGUgb2YgaXRzIGFjdGl2ZSAndG1pZHMnIG9yIGhhcyB0bw0KPiBzZXQN Cj4gICAgJ3RtaWQnIGJhY2sgdG8gemVybyAoZS5nLiwgY3Jhc2ggb3IgcmVzdGFydCkgTVVTVCBz ZW5kIGEgR0VUDQo+IHJlcXVlc3QNCj4gICAgdG8gdGhlIERPVFMgc2VydmVyIHRvIHJldHJpZXZl IHRoZSBsaXN0IG9mIGFjdGl2ZSAndG1pZCcuICBUaGUgRE9UUw0KPiAgICBjbGllbnQgbWF5IHRo ZW4gZGVsZXRlICd0bWlkcycgdGhhdCBzaG91bGQgbm90IGJlIGFjdGl2ZSBhbnltb3JlLg0KPiAN Cg0KW01lZF0gWWVzLiBUaGUgTkVXIHRleHQgd2lsbCBiZSByaWdodCBhZnRlciB0aGlzIG9uZS4g DQoNCj4gT3RoZXIgbWlub3Igbml0cw0KPiANCj4gT0xEDQo+ICAgIGF0dGFjay1zZXZlcml0eTog IEF0dGFjayBzZXZlcml0eS4gIFRoZXNlIHZhbHVlcyBhcmUgc3VwcG9ydGVkOg0KPiAgICAgICBF bWVyZ2VuY3kgKDEpLCBjcml0aWNhbCAoMiksIGFuZCBhbGVydCAoMykuDQo+IE5FVyAoY2FzZSBv ZiBlbWVyZ2VuY3kpDQo+ICAgIGF0dGFjay1zZXZlcml0eTogIEF0dGFjayBzZXZlcml0eS4gIFRo ZXNlIHZhbHVlcyBhcmUgc3VwcG9ydGVkOg0KPiAgICAgICBlbWVyZ2VuY3kgKDEpLCBjcml0aWNh bCAoMiksIGFuZCBhbGVydCAoMykuDQo+IA0KPiBPTEQNCj4gICAgdG1pZDogIFRlbGVtZXRyeSBJ ZGVudGlmaWVyIGlzIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBET1RTIHByZS1vci0NCj4gICAgICAg ICBvbmdvaW5nLW1pdGlnYXRpb24gdGVsZW1ldHJ5IGRhdGEgcmVwcmVzZW50ZWQgYXMgYW4gaW50 ZWdlci4NCj4gICAgICAgICBUaGlzIGlkZW50aWZpZXIgTVVTVCBiZSBnZW5lcmF0ZWQgYnkgRE9U UyBjbGllbnRzLiAndHNpZCcNCj4gdmFsdWVzDQo+IE5FVyB0c2lkIC0+IHRtaWQNCj4gICAgdG1p ZDogIFRlbGVtZXRyeSBJZGVudGlmaWVyIGlzIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBET1RTIHBy ZS1vci0NCj4gICAgICAgICBvbmdvaW5nLW1pdGlnYXRpb24gdGVsZW1ldHJ5IGRhdGEgcmVwcmVz ZW50ZWQgYXMgYW4gaW50ZWdlci4NCj4gICAgICAgICBUaGlzIGlkZW50aWZpZXIgTVVTVCBiZSBn ZW5lcmF0ZWQgYnkgRE9UUyBjbGllbnRzLiAndG1pZCcNCj4gdmFsdWVzDQo+IA0KDQpbTWVkXSBG aXhlZC4gVGhhbmtzLiAgDQoNCj4gUmVnYXJkcw0KPiANCj4gSm9uDQo+IA0KPiANCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiA+IFNlbnQ6 IDAyIEFwcmlsIDIwMjAgMTk6NDINCj4gPiBUbzogSm9uIFNoYWxsb3c7IEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHk7IGthbmFtZSBuaXNoaXp1a2ENCj4gPiBTdWJqZWN0OiBSRTogW0RvdHNdIE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kb3RzLQ0KPiB0ZWxlbWV0cnkt MDUudHh0DQo+ID4NCj4gPiBSZS0sDQo+ID4NCj4gPiBUaGUgc2FtZSBpc3N1ZSBhcHBsaWVzIGFz IHdlbGwgZm9yIHRoZSBiYXNlbGluZSBjb21wb25lbnQ6DQo+ID4NCj4gPiBJZiB3ZSBjb252ZXkg bXVsdGlwbGUgcHJvdG9jb2xzIGluIHRhcmdldC1wcmVmaXggYW5kIHdhbnQgdG8gc2lnbmFsDQo+ IGFsbCB0b3RhbC0NCj4gPiB0cmFmZmljLW5vcm1hbC1iYXNlbGluZSArIHRvdGFsLXRyYWZmaWMt bm9ybWFsLWJhc2VsaW5lIG9mIGVhY2gNCj4gcHJvdG9jb2wgbGlzdGVkIGluDQo+ID4gdGFyZ2V0 LXByZWZpeCwgd2Ugd2lsbCBuZWVkIHRvIGhhdmUgdG8gdXNlIGFuIGluZGV4IGluIGFkZGl0aW9u IHRvDQo+IHRoZSB1bml0Lg0KPiA+IFByb3RvY29sIGNhbiB0aGVuIGJlY29tZSBvcHRpb25hbC4g VGhlIHNhbWUgYXBwbHkgZm9yIHRvdGFsLQ0KPiBjb25uZWN0aW9uLQ0KPiA+IGNhcGFjaXR5Lg0K PiA+DQo+ID4gSSBuZWVkIHRvIHRoaW5rIGFib3V0IHRoaXMgZnVydGhlci4NCj4gPg0KPiA+IENo ZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4gPiBEZSA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPiA+IEVudm95w6kgOiBqZXVk aSAyIGF2cmlsIDIwMjAgMTk6MjkNCj4gPiA+IMOAIDogJ0pvbiBTaGFsbG93JzsgS29uZGEsIFRp cnVtYWxlc3dhciBSZWRkeTsga2FuYW1lIG5pc2hpenVrYQ0KPiA+ID4gT2JqZXQgOiBSRTogW0Rv dHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kb3RzLQ0KPiA+ID4g dGVsZW1ldHJ5LTA1LnR4dA0KPiA+ID4NCj4gPiA+IEhpIEpvbiwNCj4gPiA+DQo+ID4gPiBQbGVh c2Ugc2VlIGlubGluZS4NCj4gPiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiBNZWQNCj4gPiA+DQo+ ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPiBEZSA6IEpvbiBTaGFs bG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCj4gPiA+ID4gRW52b3nDqSA6 IG1lcmNyZWRpIDEgYXZyaWwgMjAyMCAyMzowMQ0KPiA+ID4gPiDDgCA6IEJPVUNBREFJUiBNb2hh bWVkIFRHSS9PTE47IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk7IGthbmFtZQ0KPiA+ID4gPiBu aXNoaXp1a2ENCj4gPiA+ID4gT2JqZXQgOiBSRTogW0RvdHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1kb3RzLQ0KPiA+ID4gPiB0ZWxlbWV0cnktMDUudHh0DQo+ID4g PiA+DQo+ID4gPiA+IEhpIE1lZCBldCBhbCwNCj4gPiA+ID4NCj4gPiA+ID4gT3RoZXIgbml0cyAo YXMgd2VsbCBhcyAyIGZvbGxvd2luZyBzZWN0aW9ucykNCj4gPiA+ID4NCj4gPiA+ID4gT0xEOg0K PiA+ID4gPg0KPiA+ID4gPiAgICBvbmdvaW5nLW1pdGlnYXRpb24gdGVsZW1ldHJ5IGRhdGEgZnJv bSB0aGUgRE9UUyBzZXJ2ZXIuICBUaGUNCj4gR0VUDQo+ID4gPiA+ICAgIHJlcXVlc3Qgc3BlY2lm eSBhICd0bWlkJyAoRmlndXJlIDMxKSBvciBub3QgKEZpZ3VyZSAzMikuDQo+ID4gPiA+DQo+ID4g PiA+IE5FVzoNCj4gPiA+ID4NCj4gPiA+ID4gICAgb25nb2luZy1taXRpZ2F0aW9uIHRlbGVtZXRy eSBkYXRhIGZyb20gdGhlIERPVFMgc2VydmVyLiAgVGhlDQo+IEdFVA0KPiA+ID4gPiAgICByZXF1 ZXN0IHNwZWNpZmllcyBhICd0bWlkJyAoRmlndXJlIDMxKSBvciBub3QgKEZpZ3VyZSAzMikuDQo+ ID4gPiA+DQo+ID4gPg0KPiA+ID4gW01lZF0gRml4ZWQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4g REVMRVRFIC90bQ0KPiA+ID4gPg0KPiA+ID4gPiBEb2VzIG5vIHRtaWQ9IGRlbGV0ZSBhbGwgdG1p ZHMgPw0KPiA+ID4gPiAtIEluIHBhcnRpY3VsYXIgYWZ0ZXIgYSByZXN0YXJ0IG9mIGEgY2xpZW50 Pw0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IFtNZWRdIFllcywgdGhleSBzaG91bGQgYmUgImRlYWN0 aXZhdGVkIi4NCj4gPiA+DQo+ID4gPiBORVc6DQo+ID4gPiAiU2VuZGluZyBhIERFTEVURSB3aXRo IG5vICd0bWlkJyBpbmRpY2F0ZXMgdGhhdCBhbGwgJ3RtaWRzJyBtdXN0DQo+IGJlDQo+ID4gPiBk ZWFjdGl2YXRlZC4iDQo+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLi4gVGhlIGJlbG93IGlz IGNvbWluZyBmcm9tIHdoYXQgdGhlIHNlcnZlciBzZW5kcyB0byB0aGUNCj4gY2xpZW50DQo+ID4g PiA+IHBlcnNwZWN0aXZlLiAgSQ0KPiA+ID4gPiA+IGFjY2VwdCB0aGF0IGluIHRoZSBjbGllbnQg c2VuZGluZyB0byB0aGUgc2VydmVyIGhhdmluZyB0YXJnZXQtDQo+ID4gPiA+IHByb3RvY29sIGFu ZA0KPiA+ID4gPiA+IHByb3RvY29sIG1heSBnaXZlIHJpc2UgdG8gc29tZSBwb3RlbnRpYWwgY29u ZnVzaW9uLi4uDQo+ID4gPiA+ID4NCj4gPiA+DQo+ID4gPiBbTWVkXSBMZXQncyBzZWUgaG93IHRv IGF2b2lkIHRoZSBpbmNvbnNpc3RlbmN5LiBUaGUgWUFORyBtb2R1bGUgaXMNCj4gPiA+IGN1cnJl bnRseSByZWZsZWN0aW5nIHRoZSB0ZXh0IHdlIGhhdmUgSSBkcmFmdC1pZXRmLWRvdHMtdGVsZW1l dHJ5LQ0KPiA+ID4gMDQjc2VjdGlvbi03LjEuIFdlIG5lZWQgdG8gY2hlY2sgdGhhdCBzZWN0aW9u IHRvIHNlZSB3aGVyZSB0aGUNCj4gcGVyLQ0KPiA+ID4gdHJhbnNwb3J0IGlzIG1lbnRpb25lZCBh bmQgbWFrZSBzdXJlIHdlIGRvbid0IGJyZWFrIHRoaW5ncy4NCj4gPiA+DQo+ID4gPiBGb3IgZXhh bXBsZSwgaWYgcHJvdG9jb2wgaXMgcHJlc2VudCBpbiB0aGUgdGFyZ2V0LCB3ZSB0byBhdm9pZA0K PiA+ID4gY29uZmxpY3RpbmcgKGFuZCByZWR1bmRhbnQpIGluZm9ybWF0aW9uIHRvIGJlIHN1cHBs aWVkIGluIHRoZQ0KPiA+ID4gdGVsZW1ldHJ5IGRhdGEuDQo+ID4gPg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IEluIHRlcm1zIG9mIHByb3RvY29sLCB0aGVyZSBhcmUgc3RpbGwgc29tZSBjb25z aXN0ZW5jaWVzDQo+IGV2ZW4gaWYNCj4gPiA+ID4geW91IGFjY2VwdCB0aGUNCj4gPiA+ID4gPiA+ IGFyZ3VtZW50IHRoYXQgcHJvdG9jb2wgaXMgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBtaXRpZ2F0 aW9uDQo+ID4gPiBzY29wZQ0KPiA+ID4gPiAod2hpY2ggSSBhbQ0KPiA+ID4gPiA+ID4gbm90IGhh cHB5IHdpdGgpLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IDEpIHRhcmdldC1wcm90b2NvbCBp cyBvcHRpb25hbGx5IHNldCBhbmQgaXQgaXMgYW4gYXJyYXkNCj4gd2hlcmVhcw0KPiA+ID4gPiBw cm90b2NvbCBpcw0KPiA+ID4gPiA+IHNpbmd1bGFyDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g MikgcHJvdG9jb2wgaXMgZGVmaW5lZCBtaXRpZ2F0aW9uIHNjb3BlIGF1Z21lbnQgYXMgcGVyDQo+ ID4gPiA+ID4gPiBtb2R1bGU6IGlldGYtZG90cy10ZWxlbWV0cnkNCj4gPiA+ID4gPiA+ICAgYXVn bWVudCAvaWV0Zi1zaWduYWw6ZG90cy1zaWduYWwvaWV0Zi1zaWduYWw6bWVzc2FnZS0NCj4gPiA+ IHR5cGUvaWV0Zi0NCj4gPiA+ID4gPiBzaWduYWw6bWl0aWdhdGlvbi0NCj4gPiA+ID4gPiA+IHNj b3BlL2lldGYtc2lnbmFsOnNjb3BlOg0KPiA+ID4gPiA+ID4gICAgICstLXJvIHRvdGFsLXRyYWZm aWMqIFt1bml0IHByb3RvY29sXSB7ZG90cy10ZWxlbWV0cnl9Pw0KPiA+ID4gPiA+ID4gICAgIHwg ICstLXJvIHVuaXQgICAgICAgICAgICAgICAgIHVuaXQNCj4gPiA+ID4gPiA+ICAgICB8ICArLS1y byBwcm90b2NvbCAgICAgICAgICAgICB1aW50OA0KPiA+ID4gPiA+ID4gICAgIHwgICstLXJvIGxv dy1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KPiA+ID4gPiA+ID4gICAgIHwgICstLXJv IG1pZC1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KPiA+ID4gPiA+ID4gICAgIHwgICst LXJvIGhpZ2gtcGVyY2VudGlsZS1nPyAgIHlhbmc6Z2F1Z2U2NA0KPiA+ID4gPiA+ID4gICAgIHwg ICstLXJvIHBlYWstZz8gICAgICAgICAgICAgIHlhbmc6Z2F1Z2U2NA0KPiA+ID4gPiA+ID4gICAg ICstLXJ3IHRvdGFsLWF0dGFjay10cmFmZmljKiBbdW5pdF0ge2RvdHMtdGVsZW1ldHJ5fT8NCj4g PiA+ID4gPiA+ICAgICB8ICArLS1ydyB1bml0ICAgICAgICAgICAgICAgICB1bml0DQo+ID4gPiA+ ID4gPiAgICAgfCAgKy0tcncgbG93LXBlcmNlbnRpbGUtZz8gICAgeWFuZzpnYXVnZTY0DQo+ID4g PiA+ID4gPiBBbmQgc28gdGhlcmUgaXMgbm8gY29uc2lzdGVuY3kgYmV0d2VlbiB0b3RhbC10cmFm ZmljIGFuZA0KPiB0b3RhbC0NCj4gPiA+ID4gYXR0YWNrLXRyYWZmaWMNCj4gPiA+DQo+ID4gPiBb TWVkXSBUaGUgaWRlYSB3YXMgdG8gaGF2ZSBhIHZpZXcgb2YgdG90YWwgdHJhZmZpYyBib3VuZCB0 byBhDQo+IHRhcmdldA0KPiA+ID4gcHJlZml4L2RvbWFpbi4gV2Ugc2hvdWxkIGNsYXJpZnkgb3Ig cmVtb3ZlIHRoZSBwcm90b2NvbCBmb3IgdGhpcw0KPiBvbmUuDQo+ID4gPiBGYWlyIGVub3VnaC4N Cj4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gMykgRm9yIC90bSB5b3UgaGF2ZQ0KPiA+ ID4gPiA+ID4gICAgICstLToodGVsZW1ldHJ5KSB7ZG90cy10ZWxlbWV0cnl9Pw0KPiA+ID4gPiA+ ID4gICAgICAgICstLXJ3IHByZS1vci1vbmdvaW5nLW1pdGlnYXRpb24qIFtjdWlkIHRtaWRdDQo+ ID4gPiA+ID4gPiAuLg0KPiA+ID4gPiA+ID4gICAgICAgICAgIHwgICstLXJ3IHRhcmdldC1wcm90 b2NvbCogICAgIHVpbnQ4DQo+ID4gPiA+ID4gPiAuLg0KPiA+ID4gPiA+ID4gICAgICAgICAgICst LXJ3IHRvdGFsLXRyYWZmaWMqIFt1bml0IHByb3RvY29sXQ0KPiA+ID4gPiA+ID4gICAgICAgICAg IHwgICstLXJ3IHVuaXQgICAgICAgICAgICAgICAgIHVuaXQNCj4gPiA+ID4gPiA+ICAgICAgICAg ICB8ICArLS1ydyBwcm90b2NvbCAgICAgICAgICAgICB1aW50OA0KPiA+ID4gPiA+ID4gLi4NCj4g PiA+ID4gPiA+ICAgICAgICAgICArLS1ydyB0b3RhbC1hdHRhY2stdHJhZmZpYyogW3VuaXQgcHJv dG9jb2xdDQo+ID4gPiA+ID4gPiAgICAgICAgICAgfCAgKy0tcncgdW5pdCAgICAgICAgICAgICAg ICAgdW5pdA0KPiA+ID4gPiA+ID4gICAgICAgICAgIHwgICstLXJ3IHByb3RvY29sICAgICAgICAg ICAgIHVpbnQ4DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQW5kIHNvIGNvdWxkIGFyZ3VlIGhl cmUgdGhhdCBwcm90b2NvbCBpcyBub3QgbmVlZGVkDQo+ID4gPg0KPiA+ID4gW01lZF0gYnV0IHdl IG1heSBoYXZlIG1hbnkgcHJvdG9jb2xzIGxpc3RlZCB1bmRlciB0YXJnZXQtcHJvdG9jb2wuDQo+ ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IDQpIElmIHRhcmdldC1wcm90b2NvbCBpcyBu b3Qgc3BlY2lmaWVkLCB0aGVuIGl0IHJlZmVycyB0bw0KPiBhbnkNCj4gPiA+ID4gcHJvdG9jb2wu ICBJZiB0YXJnZXQtDQo+ID4gPiA+ID4gPiBwcm90b2NvbCBpcyBub3QgZGVmaW5lZCBpbiAvbWl0 aWdhdGUsIHRoZW4gSSBoYXZlIG5vIHdheSBvZg0KPiA+ID4gPiBpbmRpY2F0aW5nIHdoaWNoIGlz IGENCj4gPiA+ID4gPiA+IHByb2JsZW1hdGljIHByb3RvY29sIGlmIHByb3RvY29sIGlzIG5vdCBz dXBwb3J0ZWQuDQo+ID4gPg0KPiA+ID4gW01lZF0gR29vZCBwb2ludC4gVGhpcyBvbmUgKGFuZCB0 aGUgZm9sbG93aW5nIG9uZSkganVzdGlmaWVzIHRoYXQNCj4gd2UNCj4gPiA+IG5lZWQgdG8gcmV2 aXNpdCB0aGUgZGVzaWduLg0KPiA+ID4NCj4gPiA+IFdlIGNhIGdyb3VwIHRoZSBkYXRhIGJ5IHRh cmdldC1wcm90b2NvbCBhbmQgc2VuZCBtYW55IHRtaWRzIGlmDQo+IG1hbnkNCj4gPiA+IHByb3Rv Y29scyBuZWVkIHRvIGJlIHJldHVybmVkLiBQcm90b2NvbCBjYW4gYmUgdGhlbiBvcHRpb25hbC4N Cj4gPiA+DQo+ID4gPiBXb3VsZCB0aGF0IGJlIGJldHRlcj8NCj4gPiA+DQo+ID4gPg0KPiANCg0K From nobody Fri Apr 3 01:24: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 82CE63A142F for ; Fri, 3 Apr 2020 01:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=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 fgPHdE_QERhf for ; Fri, 3 Apr 2020 01:24:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07653A1403 for ; Fri, 3 Apr 2020 01:24:04 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48ttJ319t2zFq99; Fri, 3 Apr 2020 10:24:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585902243; bh=XsR9ZofUSitNV3rUF5ByJdgmqTzKLFr/tnxlC8lHFYQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=J9Zoct5hxuaCOj+9H4c93YT9PL1mJKqq2MSNMA6wRUVherJjzU2YswbbpMpuI5Rah gUTdSBNeqf+c/0Q7k7Sgo+UJfH0LIBEJtTGdQovCzpTOeI4rA/32XbATM7JFlc8KhS N0Af1WQIpmh7/LwGV8s7Gut3TVYmgkttqC4/ksI6moZT2q9z5u0bCyd+FU5aLlQaJ8 mAvlvbSRh1rSQciYUiYD+weDX16U1IVW8VeqMjwiwvJskjjobv2+fKsgzMThS3NS42 Y4FchuGJFHbsziZ+tCUk6U4/+GovZ+8wz2UCL+Oo/Pe+M9zycUpmZzneNnS49um9BH 2tQnGVpBruuWA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 48ttJ305Z0zCqkY; Fri, 3 Apr 2020 10:24:03 +0200 (CEST) From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka CC: "dots@ietf.org" Thread-Topic: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AQKpDKSlae91Qx1rveAaG4y93fawwwGS0CN0ActngzYBop/8/AGLlQYiAqtlZCwC5xXv2wJXxJ8rAWqlVlgB+pAcCQK0mLlyAOa0qGymFG2a0IAAsLmggAAwQqA= Date: Fri, 3 Apr 2020 08:24:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148D71C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158532456961.24330.9684049527965442282@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303148203F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0acd01d60458$9df439f0$d9dcadd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031482353@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0b7501d604f9$40fd53c0$c2f7fb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031483683@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0db001d606d0$3f6312b0$be293810$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031489524@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ed901d6079d$ad34b1e0$079e15a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148B373@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <101201d60868$affd91a0$0ff8b4e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148D091@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <112b01d60927$b2ae7300$180b5900$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148D4EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148D4EE@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 08:24:07 -0000 Sm9uLCANCg0KRldJVywgdGhlIHByb3Bvc2VkIGNoYW5nZSBvbiB0aGUgdHJlZSBkaWFncmFtIGNh biBiZSBzZWVuIGhlcmU6IA0KDQpodHRwczovL2dpdGh1Yi5jb20vYm91Y2FkYWlyL2RyYWZ0LWRv dHMtdGVsZW1ldHJ5L2NvbW1pdC9lYTdjMjEwMWM0ZDNmNzQ4ODA4YzI1ZmE4NTkwMGZjYTdiY2Ey NzNiI2RpZmYtMzdjOWVjN2E5YTg0OThjNmRjMzgyOWRlZWY3OWI1ZTcgDQoNCk9mIGNvdXJzZSwg dGhpcyBpcyBhIHByb3Bvc2FsIGZvciBkaXNjdXNzaW9uLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDMgYXZyaWwgMjAyMCAwNzo1NA0KPiDDgMKgOiBK b24gU2hhbGxvdzsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsga2FuYW1lIG5pc2hpenVrYQ0K PiBDY8KgOiBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbRG90c10gTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRvdHMtDQo+IHRlbGVtZXRyeS0wNS50eHQNCj4g DQo+IEhpIEpvbiwNCj4gDQo+IE1vdmluZyB0aGUgZGlzY3Vzc2lvbiB0byB0aGUgV0cgbGlzdCBh cyB0aGlzIGlzIGFuIGltcG9ydGFudCBkZXNpZ24NCj4gY2hhbmdlIHdlIG5lZWQgdG8gbWFrZS4N Cj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogSm9uIFNoYWxsb3cgW21haWx0 bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KPiA+IEVudm95w6nCoDogamV1ZGkgMiBhdnJp bCAyMDIwIDIxOjQ5DQo+ID4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeTsga2FuYW1lDQo+ID4gbmlzaGl6dWthDQo+ID4gT2JqZXTCoDog UkU6IFtEb3RzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90cy0N Cj4gPiB0ZWxlbWV0cnktMDUudHh0DQo+ID4NCj4gPiBTdGVwcGluZyBiYWNrIHRvIGxvb2sgYXQg dGhlIGJpZ2dlciBwaWN0dXJlLCBJIHRoaW5rIHRoYXQgSSB3b3VsZCBiZQ0KPiA+IG1vcmUgaW50 ZXJlc3RlZCBpbiB0aGUgZGV0YWlsIG9mIGEgcG90ZW50aWFsbHkgbXVsdGktdmVjdG9yZWQNCj4g bXV0YXRpbmcNCj4gPiBhdHRhY2ssIGFuZCBzbyBxdWVzdGlvbiB3aGV0aGVyIGhhdmluZyB0YXJn ZXQtcHJvdG9jb2wgYXMgYW4gb3ZlcmFsbA0KPiA+IHJlc3RyaWN0aXZlIHZpZXcgb2YgYWxsIHRo ZSBkZXRhaWwgbWFrZXMgc2Vuc2UuICBJdCBpcyBlYXNpZXIgdG8NCj4gPiBmaWx0ZXIgb3V0IGRh dGEgdGhhdCBJIGRvIG5vdCB3YW50IC8gY2FyZSBhYm91dCBhZnRlciByZWNlaXZpbmcgaXQuDQo+ ID4gVGhlIHJlbW90ZSBwZWVyIG1heSBub3QgaGF2ZSB0aGUgc2FtZSB2aWV3IG9mIHdoYXQgdG8g c2VuZCB2IHdoYXQgSQ0KPiBhbQ0KPiA+IGludGVyZXN0ZWQgaW4uDQo+ID4NCj4gPiBbSSBhbSBj b25jZXJuZWQgYWJvdXQgb3Zlci1maWxsaW5nIGEgcGFja2V0IGFuZCBoYXZpbmcgdG8gZ28gaW50 bw0KPiBDb0FQDQo+ID4gQmxvY2syIG1vZGUgdGhvdWdoIHdoaWNoIHdpbGwgZmFpbCBvbiBhIHNh dHVyYXRlZCBsaW5rLiAgSSBoYXZlIG5vdA0KPiA+IGRvbmUgYW55IHNpemluZyBvZiB0aGF0IHll dCB3aXRoIGdlbnVpbmUgYXR0YWNrIGluZm9ybWF0aW9uXQ0KPiA+DQo+ID4gU28sIGZvciB0aGUg L3RtIGFuZCAvdG0tc2V0dXAgc3R1ZmYgZG8gd2UgcmVhbGx5IG5lZWQgdGFyZ2V0LQ0KPiBwcm90 b2NvbA0KPiA+IGFuZCBjb3VsZCBqdXN0IGhhdmUgcHJvdG9jb2wgYXMgYW4gb3B0aW9uYWwsIGJ1 dCBhcnJheSwgZW50aXR5Pw0KPiANCj4gW01lZF0gSXQgaXMgaW1wb3J0YW50IHRvIHByb3ZpZGUg ZGV0YWlscyBwZXIgcHJvdG9jb2wgYXMgdGhpcyB3aWxsDQo+IGhlbHAgaWRlbnRpZnlpbmcgYWJu b3JtYWwgcGF0dGVybnMuDQo+IA0KPiBXZSBjb3VsZCBhc3NvY2lhdGUgMCB0byBtZWFuICJhbGwi IHByb3RvY29scyBidXQgSSBrbm93IHRoaXMgd2lsbCBodXJ0DQo+IG1hbnkuIFdlIGNhbiBjb25z aWRlciB0aGUgZm9sbG93aW5nIGNoYW5nZToNCj4gDQo+IE9MRA0KPiANCj4gICAgIHwgICAgICAg ICAgICstLXJ3IGJhc2VsaW5lKiBbaWRdDQo+ICAgICB8ICAgICAgICAgICAgICArLS1ydyBpZCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzINCj4gICAgIHwgICAgICAgICAgICAg ICstLXJ3IHRhcmdldC1wcmVmaXgqICAgICAgICAgICAgICAgICAgIGluZXQ6aXAtDQo+IHByZWZp eA0KPiAgICAgfCAgICAgICAgICAgICAgKy0tcncgdGFyZ2V0LXBvcnQtcmFuZ2UqIFtsb3dlci1w b3J0XQ0KPiAgICAgfCAgICAgICAgICAgICAgfCAgKy0tcncgbG93ZXItcG9ydCAgICBpbmV0OnBv cnQtbnVtYmVyDQo+ICAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyB1cHBlci1wb3J0PyAgIGlu ZXQ6cG9ydC1udW1iZXINCj4gICAgIHwgICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcm90b2Nv bCogICAgICAgICAgICAgICAgIHVpbnQ4DQo+ICAgICB8ICAgICAgICAgICAgICArLS1ydyB0YXJn ZXQtZnFkbiogICAgICAgICAgICAgICAgICAgICBpbmV0OmRvbWFpbi0NCj4gbmFtZQ0KPiAgICAg fCAgICAgICAgICAgICAgKy0tcncgdGFyZ2V0LXVyaSogICAgICAgICAgICAgICAgICAgICAgaW5l dDp1cmkNCj4gICAgIHwgICAgICAgICAgICAgICstLXJ3IHRvdGFsLXRyYWZmaWMtbm9ybWFsLWJh c2VsaW5lKiBbdW5pdA0KPiBwcm90b2NvbF0NCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3 IHVuaXQgICAgICAgICAgICAgICAgIHVuaXQNCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3 IHByb3RvY29sICAgICAgICAgICAgIHVpbnQ4DQo+ICAgICB8ICAgICAgICAgICAgICB8ICArLS1y dyBsb3ctcGVyY2VudGlsZS1nPyAgICB5YW5nOmdhdWdlNjQNCj4gICAgIHwgICAgICAgICAgICAg IHwgICstLXJ3IG1pZC1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KPiAgICAgfCAgICAg ICAgICAgICAgfCAgKy0tcncgaGlnaC1wZXJjZW50aWxlLWc/ICAgeWFuZzpnYXVnZTY0DQo+ICAg ICB8ICAgICAgICAgICAgICB8ICArLS1ydyBwZWFrLWc/ICAgICAgICAgICAgICB5YW5nOmdhdWdl NjQNCj4gDQo+IE5FVzoNCj4gDQo+ICAgICB8ICAgICAgICArLS06KGJhc2VsaW5lKQ0KPiAgICAg fCAgICAgICAgICAgKy0tcncgYmFzZWxpbmUqIFtpZF0NCj4gICAgIHwgICAgICAgICAgICAgICst LXJ3IGlkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzINCj4gICAgIHwg ICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wcmVmaXgqICAgICAgICAgICAgICAgICAgICAgICBp bmV0OmlwLQ0KPiBwcmVmaXgNCj4gICAgIHwgICAgICAgICAgICAgICstLXJ3IHRhcmdldC1wb3J0 LXJhbmdlKiBbbG93ZXItcG9ydF0NCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGxvd2Vy LXBvcnQgICAgaW5ldDpwb3J0LW51bWJlcg0KPiAgICAgfCAgICAgICAgICAgICAgfCAgKy0tcncg dXBwZXItcG9ydD8gICBpbmV0OnBvcnQtbnVtYmVyDQo+ICAgICB8ICAgICAgICAgICAgICArLS1y dyB0YXJnZXQtcHJvdG9jb2wqICAgICAgICAgICAgICAgICAgICAgdWludDgNCj4gICAgIHwgICAg ICAgICAgICAgICstLXJ3IHRhcmdldC1mcWRuKg0KPiBpbmV0OmRvbWFpbi1uYW1lDQo+ICAgICB8 ICAgICAgICAgICAgICArLS1ydyB0YXJnZXQtdXJpKiAgICAgICAgICAgICAgICAgICAgICAgICAg aW5ldDp1cmkNCj4gICAgIHwgICAgICAgICAgICAgICstLXJ3IGFsaWFzLW5hbWUqICAgICAgICAg ICAgICAgICAgICAgICAgICBzdHJpbmcNCj4gICAgIHwgICAgICAgICAgICAgICstLXJ3IHRvdGFs LXRyYWZmaWMtbm9ybWFsKiBbdW5pdF0NCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHVu aXQgICAgICAgICAgICAgICAgIHVuaXQNCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGxv dy1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KPiAgICAgfCAgICAgICAgICAgICAgfCAg Ky0tcncgbWlkLXBlcmNlbnRpbGUtZz8gICAgeWFuZzpnYXVnZTY0DQo+ICAgICB8ICAgICAgICAg ICAgICB8ICArLS1ydyBoaWdoLXBlcmNlbnRpbGUtZz8gICB5YW5nOmdhdWdlNjQNCj4gICAgIHwg ICAgICAgICAgICAgIHwgICstLXJ3IHBlYWstZz8gICAgICAgICAgICAgIHlhbmc6Z2F1Z2U2NA0K PiAgICAgfCAgICAgICAgICAgICAgKy0tcncgdG90YWwtdHJhZmZpYy1ub3JtYWwtcGVyLXByb3Rv Y29sKiBbdW5pdA0KPiBwcm90b2NvbF0NCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHVu aXQgICAgICAgICAgICAgICAgIHVuaXQNCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IHBy b3RvY29sICAgICAgICAgICAgIHVpbnQ4DQo+ICAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyBs b3ctcGVyY2VudGlsZS1nPyAgICB5YW5nOmdhdWdlNjQNCj4gICAgIHwgICAgICAgICAgICAgIHwg ICstLXJ3IG1pZC1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KPiAgICAgfCAgICAgICAg ICAgICAgfCAgKy0tcncgaGlnaC1wZXJjZW50aWxlLWc/ICAgeWFuZzpnYXVnZTY0DQo+ICAgICB8 ICAgICAgICAgICAgICB8ICArLS1ydyBwZWFrLWc/ICAgICAgICAgICAgICB5YW5nOmdhdWdlNjQN Cj4gDQo+IE9mIGNvdXJzZSwgdGhlIHByb3RvY29sIG11c3QgYmUgbGlzdGVkIGluIHRhcmdldC1w cm90b2NvbCAoaWYNCj4gcHJlc2VudCkuDQo+IA0KPiA+DQo+ID4gVGhlbiBmb3IgL21pdGlnYXRl LCB0YXJnZXQtcHJvdG9jb2wgaXMgaWdub3JlZCBpbiBkZWNpZGluZyB3aGF0IHRvDQo+ID4gc2Vu ZCBiYWNrLCBidXQgdGhlIHVzZSBvZiBhbiBvcHRpb25hbCBwcm90b2NvbCBhcnJheSBjYW4gcmVk dWNlIHNvbWUNCj4gPiBvZiB0aGUgcGFja2V0IHNpemUuDQo+ID4NCj4gPiB0b3RhbC1hdHRhY2st Y29ubmVjdGlvbiAgLyB0b3RhbC1jb25uZWN0aW9uLWNhcGFjaXR5IHdpbGwgb25seSBiZQ0KPiBm b3INCj4gPiBjb25uZWN0aW9uIGJhc2VkIGNvbm5lY3Rpb25zIC0gcHJpbWFyaWx5IFRDUCBJIHN1 c3BlY3QuDQo+IA0KPiBbTWVkXSBBZ3JlZS4NCj4gDQo+ICBIb3dldmVyDQo+ID4gKHRhcmdldCkg cG9ydHMgbWF5IGJlIHJlbGV2YW50IGhlcmUgLSBhIHNlcnZlciBtYXkgYmUgYWJsZSB0bw0KPiBz dXBwb3J0DQo+ID4gWCBIVFRQUyBjb25uZWN0aW9ucywgYnV0IG9ubHkgWSBETlMgKFRDUCkgY29u bmVjdGlvbnMgLSBvciBhIGxvYWQtDQo+ID4gYmFsYW5jZXIgaW4gdGhlIHBhdGggaXMgb25seSAg Y2FwYWJsZSBvZiBoYW5kbGluZyBaIGNvbm5lY3Rpb25zIC0gbm8NCj4gPiBtYXR0ZXIgd2hhdCB0 aGUgcG9ydCBpcy4uICBTbywgZG8gd2Ugd2FudCB0byBpbnRyb2R1Y2Ugb3B0aW9uYWwNCj4gcG9y dHM/DQo+IA0KPiBbTWVkXSBUaGVzZSBwb3J0cyBoYXZlIHRvIGJlIGxpc3RlZCBpbiB0YXJnZXQt cG9ydC1yYW5nZSAoaWYgcHJlc2VudCkuDQo+IElmIHdlIGluY2x1ZGUgcG9ydCB0byB0aGUgZXhp c3RpbmcgbGlzdCwgd2UgY2FuJ3QgbWFpbnRhaW4gdHdvIGVudHJpZXMNCj4gZm9yIHRoZSBzYW1l IHByb3RvY29sIGJ1dCB3aXRoIGRpc3RpbmN0IHBvcnQuIEl0IG1heSBiZSBtb3JlIHNpbXBsZSB0 bw0KPiBtYWtlIHRoaXMgY2hhbmdlOg0KPiANCj4gT0xEOg0KPiAgICAgfCAgICAgICAgICAgICAg Ky0tcncgdG90YWwtY29ubmVjdGlvbi1jYXBhY2l0eSogW3Byb3RvY29sXQ0KPiAgICAgfCAgICAg ICAgICAgICAgICAgKy0tcncgcHJvdG9jb2wgICAgICAgICAgICAgICAgICAgICB1aW50OA0KPiAg ICAgfCAgICAgICAgICAgICAgICAgKy0tcncgY29ubmVjdGlvbj8gICAgICAgICAgICAgICAgICB1 aW50NjQNCj4gICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IGNvbm5lY3Rpb24tY2xpZW50PyAg ICAgICAgICAgdWludDY0DQo+ICAgICB8ICAgICAgICAgICAgICAgICArLS1ydyBlbWJyeW9uaWM/ ICAgICAgICAgICAgICAgICAgIHVpbnQ2NA0KPiAgICAgfCAgICAgICAgICAgICAgICAgKy0tcncg ZW1icnlvbmljLWNsaWVudD8gICAgICAgICAgICB1aW50NjQNCj4gICAgIHwgICAgICAgICAgICAg ICAgICstLXJ3IGNvbm5lY3Rpb24tcHM/ICAgICAgICAgICAgICAgdWludDY0DQo+ICAgICB8ICAg ICAgICAgICAgICAgICArLS1ydyBjb25uZWN0aW9uLWNsaWVudC1wcz8gICAgICAgIHVpbnQ2NA0K PiAgICAgfCAgICAgICAgICAgICAgICAgKy0tcncgcmVxdWVzdC1wcz8gICAgICAgICAgICAgICAg ICB1aW50NjQNCj4gICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IHJlcXVlc3QtY2xpZW50LXBz PyAgICAgICAgICAgdWludDY0DQo+ICAgICB8ICAgICAgICAgICAgICAgICArLS1ydyBwYXJ0aWFs LXJlcXVlc3QtcHM/ICAgICAgICAgIHVpbnQ2NA0KPiAgICAgfCAgICAgICAgICAgICAgICAgKy0t cncgcGFydGlhbC1yZXF1ZXN0LWNsaWVudC1wcz8gICB1aW50NjQNCj4gDQo+IE5FVzoNCj4gDQo+ ICAgICB8ICAgICAgICAgICAgICArLS1ydyB0b3RhbC1jb25uZWN0aW9uLWNhcGFjaXR5KiBbcHJv dG9jb2xdDQo+ICAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyBwcm90b2NvbCAgICAgICAgICAg ICAgICAgICAgIHVpbnQ4DQo+ICAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyBjb25uZWN0aW9u PyAgICAgICAgICAgICAgICAgIHVpbnQ2NA0KPiAgICAgfCAgICAgICAgICAgICAgfCAgKy0tcncg Y29ubmVjdGlvbi1jbGllbnQ/ICAgICAgICAgICB1aW50NjQNCj4gICAgIHwgICAgICAgICAgICAg IHwgICstLXJ3IGVtYnJ5b25pYz8gICAgICAgICAgICAgICAgICAgdWludDY0DQo+ICAgICB8ICAg ICAgICAgICAgICB8ICArLS1ydyBlbWJyeW9uaWMtY2xpZW50PyAgICAgICAgICAgIHVpbnQ2NA0K PiAgICAgfCAgICAgICAgICAgICAgfCAgKy0tcncgY29ubmVjdGlvbi1wcz8gICAgICAgICAgICAg ICB1aW50NjQNCj4gICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGNvbm5lY3Rpb24tY2xpZW50 LXBzPyAgICAgICAgdWludDY0DQo+ICAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyByZXF1ZXN0 LXBzPyAgICAgICAgICAgICAgICAgIHVpbnQ2NA0KPiAgICAgfCAgICAgICAgICAgICAgfCAgKy0t cncgcmVxdWVzdC1jbGllbnQtcHM/ICAgICAgICAgICB1aW50NjQNCj4gICAgIHwgICAgICAgICAg ICAgIHwgICstLXJ3IHBhcnRpYWwtcmVxdWVzdC1wcz8gICAgICAgICAgdWludDY0DQo+ICAgICB8 ICAgICAgICAgICAgICB8ICArLS1ydyBwYXJ0aWFsLXJlcXVlc3QtY2xpZW50LXBzPyAgIHVpbnQ2 NA0KPiAgICAgfCAgICAgICAgICAgICAgKy0tcncgdG90YWwtY29ubmVjdGlvbi1jYXBhY2l0eS1w ZXItcG9ydCogW3Byb3RvY29sDQo+IGxvd2VyLXBvcnRdDQo+ICAgICB8ICAgICAgICAgICAgICAg ICArLS1ydyBwcm90b2NvbCAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQo+ICAgICB8ICAgICAg ICAgICAgICAgICArLS1ydyBsb3dlci1wb3J0ICAgICAgICAgICAgICAgICAgIGluZXQ6cG9ydC0N Cj4gbnVtYmVyDQo+ICAgICB8ICAgICAgICAgICAgICAgICArLS1ydyBjb25uZWN0aW9uPyAgICAg ICAgICAgICAgICAgIHVpbnQ2NA0KPiAgICAgfCAgICAgICAgICAgICAgICAgKy0tcncgY29ubmVj dGlvbi1jbGllbnQ/ICAgICAgICAgICB1aW50NjQNCj4gICAgIHwgICAgICAgICAgICAgICAgICst LXJ3IGVtYnJ5b25pYz8gICAgICAgICAgICAgICAgICAgdWludDY0DQo+ICAgICB8ICAgICAgICAg ICAgICAgICArLS1ydyBlbWJyeW9uaWMtY2xpZW50PyAgICAgICAgICAgIHVpbnQ2NA0KPiAgICAg fCAgICAgICAgICAgICAgICAgKy0tcncgY29ubmVjdGlvbi1wcz8gICAgICAgICAgICAgICB1aW50 NjQNCj4gICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IGNvbm5lY3Rpb24tY2xpZW50LXBzPyAg ICAgICAgdWludDY0DQo+ICAgICB8ICAgICAgICAgICAgICAgICArLS1ydyByZXF1ZXN0LXBzPyAg ICAgICAgICAgICAgICAgIHVpbnQ2NA0KPiAgICAgfCAgICAgICAgICAgICAgICAgKy0tcncgcmVx dWVzdC1jbGllbnQtcHM/ICAgICAgICAgICB1aW50NjQNCj4gICAgIHwgICAgICAgICAgICAgICAg ICstLXJ3IHBhcnRpYWwtcmVxdWVzdC1wcz8gICAgICAgICAgdWludDY0DQo+ICAgICB8ICAgICAg ICAgICAgICAgICArLS1ydyBwYXJ0aWFsLXJlcXVlc3QtY2xpZW50LXBzPyAgIHVpbnQ2NA0KPiAN Cj4gPg0KPiA+ID4gPiBORVc6DQo+ID4gPiA+ICJTZW5kaW5nIGEgREVMRVRFIHdpdGggbm8gJ3Rt aWQnIGluZGljYXRlcyB0aGF0IGFsbCAndG1pZHMnIG11c3QNCj4gPiBiZQ0KPiA+ID4gPiBkZWFj dGl2YXRlZC4iDQo+ID4gPiA+DQo+ID4NCj4gPiBJIGZvdW5kIHRoaXMgKGJ1dCBJIHByZWZlciB5 b3VyIGFkZGl0aW9uIGZvciBjb25zaXN0ZW5jeSkNCj4gPg0KPiA+ICAgIEEgRE9UUyBjbGllbnQg dGhhdCBsb3N0IHRoZSBzdGF0ZSBvZiBpdHMgYWN0aXZlICd0bWlkcycgb3IgaGFzIHRvDQo+ID4g c2V0DQo+ID4gICAgJ3RtaWQnIGJhY2sgdG8gemVybyAoZS5nLiwgY3Jhc2ggb3IgcmVzdGFydCkg TVVTVCBzZW5kIGEgR0VUDQo+ID4gcmVxdWVzdA0KPiA+ICAgIHRvIHRoZSBET1RTIHNlcnZlciB0 byByZXRyaWV2ZSB0aGUgbGlzdCBvZiBhY3RpdmUgJ3RtaWQnLiAgVGhlDQo+IERPVFMNCj4gPiAg ICBjbGllbnQgbWF5IHRoZW4gZGVsZXRlICd0bWlkcycgdGhhdCBzaG91bGQgbm90IGJlIGFjdGl2 ZSBhbnltb3JlLg0KPiA+DQo+IA0KPiBbTWVkXSBZZXMuIFRoZSBORVcgdGV4dCB3aWxsIGJlIHJp Z2h0IGFmdGVyIHRoaXMgb25lLg0KPiANCj4gPiBPdGhlciBtaW5vciBuaXRzDQo+ID4NCj4gPiBP TEQNCj4gPiAgICBhdHRhY2stc2V2ZXJpdHk6ICBBdHRhY2sgc2V2ZXJpdHkuICBUaGVzZSB2YWx1 ZXMgYXJlIHN1cHBvcnRlZDoNCj4gPiAgICAgICBFbWVyZ2VuY3kgKDEpLCBjcml0aWNhbCAoMiks IGFuZCBhbGVydCAoMykuDQo+ID4gTkVXIChjYXNlIG9mIGVtZXJnZW5jeSkNCj4gPiAgICBhdHRh Y2stc2V2ZXJpdHk6ICBBdHRhY2sgc2V2ZXJpdHkuICBUaGVzZSB2YWx1ZXMgYXJlIHN1cHBvcnRl ZDoNCj4gPiAgICAgICBlbWVyZ2VuY3kgKDEpLCBjcml0aWNhbCAoMiksIGFuZCBhbGVydCAoMyku DQo+ID4NCj4gPiBPTEQNCj4gPiAgICB0bWlkOiAgVGVsZW1ldHJ5IElkZW50aWZpZXIgaXMgYW4g aWRlbnRpZmllciBmb3IgdGhlIERPVFMgcHJlLW9yLQ0KPiA+ICAgICAgICAgb25nb2luZy1taXRp Z2F0aW9uIHRlbGVtZXRyeSBkYXRhIHJlcHJlc2VudGVkIGFzIGFuIGludGVnZXIuDQo+ID4gICAg ICAgICBUaGlzIGlkZW50aWZpZXIgTVVTVCBiZSBnZW5lcmF0ZWQgYnkgRE9UUyBjbGllbnRzLiAn dHNpZCcNCj4gPiB2YWx1ZXMNCj4gPiBORVcgdHNpZCAtPiB0bWlkDQo+ID4gICAgdG1pZDogIFRl bGVtZXRyeSBJZGVudGlmaWVyIGlzIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBET1RTIHByZS1vci0N Cj4gPiAgICAgICAgIG9uZ29pbmctbWl0aWdhdGlvbiB0ZWxlbWV0cnkgZGF0YSByZXByZXNlbnRl ZCBhcyBhbiBpbnRlZ2VyLg0KPiA+ICAgICAgICAgVGhpcyBpZGVudGlmaWVyIE1VU1QgYmUgZ2Vu ZXJhdGVkIGJ5IERPVFMgY2xpZW50cy4gJ3RtaWQnDQo+ID4gdmFsdWVzDQo+ID4NCj4gDQo+IFtN ZWRdIEZpeGVkLiBUaGFua3MuDQo+IA0KPiA+IFJlZ2FyZHMNCj4gPg0KPiA+IEpvbg0KPiA+DQo+ ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tXQ0KPiA+ID4gU2VudDogMDIgQXByaWwgMjAyMCAxOTo0Mg0KPiA+ID4gVG86IEpvbiBT aGFsbG93OyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBrYW5hbWUgbmlzaGl6dWthDQo+ID4g PiBTdWJqZWN0OiBSRTogW0RvdHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aWV0Zi1kb3RzLQ0KPiA+IHRlbGVtZXRyeS0wNS50eHQNCj4gPiA+DQo+ID4gPiBSZS0sDQo+ID4g Pg0KPiA+ID4gVGhlIHNhbWUgaXNzdWUgYXBwbGllcyBhcyB3ZWxsIGZvciB0aGUgYmFzZWxpbmUg Y29tcG9uZW50Og0KPiA+ID4NCj4gPiA+IElmIHdlIGNvbnZleSBtdWx0aXBsZSBwcm90b2NvbHMg aW4gdGFyZ2V0LXByZWZpeCBhbmQgd2FudCB0bw0KPiBzaWduYWwNCj4gPiBhbGwgdG90YWwtDQo+ ID4gPiB0cmFmZmljLW5vcm1hbC1iYXNlbGluZSArIHRvdGFsLXRyYWZmaWMtbm9ybWFsLWJhc2Vs aW5lIG9mIGVhY2gNCj4gPiBwcm90b2NvbCBsaXN0ZWQgaW4NCj4gPiA+IHRhcmdldC1wcmVmaXgs IHdlIHdpbGwgbmVlZCB0byBoYXZlIHRvIHVzZSBhbiBpbmRleCBpbiBhZGRpdGlvbiB0bw0KPiA+ IHRoZSB1bml0Lg0KPiA+ID4gUHJvdG9jb2wgY2FuIHRoZW4gYmVjb21lIG9wdGlvbmFsLiBUaGUg c2FtZSBhcHBseSBmb3IgdG90YWwtDQo+ID4gY29ubmVjdGlvbi0NCj4gPiA+IGNhcGFjaXR5Lg0K PiA+ID4NCj4gPiA+IEkgbmVlZCB0byB0aGluayBhYm91dCB0aGlzIGZ1cnRoZXIuDQo+ID4gPg0K PiA+ID4gQ2hlZXJzLA0KPiA+ID4gTWVkDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4gPiA+ID4gRGUgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+ID4g PiA+IEVudm95w6kgOiBqZXVkaSAyIGF2cmlsIDIwMjAgMTk6MjkNCj4gPiA+ID4gw4AgOiAnSm9u IFNoYWxsb3cnOyBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBrYW5hbWUgbmlzaGl6dWthDQo+ ID4gPiA+IE9iamV0IDogUkU6IFtEb3RzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtZG90cy0NCj4gPiA+ID4gdGVsZW1ldHJ5LTA1LnR4dA0KPiA+ID4gPg0KPiA+ID4g PiBIaSBKb24sDQo+ID4gPiA+DQo+ID4gPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ID4gPg0K PiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+IE1lZA0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPiA+IERlIDogSm9uIFNoYWxsb3cgW21haWx0bzpz dXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KPiA+ID4gPiA+IEVudm95w6kgOiBtZXJjcmVkaSAx IGF2cmlsIDIwMjAgMjM6MDENCj4gPiA+ID4gPiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9P TE47IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHk7DQo+IGthbmFtZQ0KPiA+ID4gPiA+IG5pc2hp enVrYQ0KPiA+ID4gPiA+IE9iamV0IDogUkU6IFtEb3RzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtDQo+IGRvdHMtDQo+ID4gPiA+ID4gdGVsZW1ldHJ5LTA1LnR4dA0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkgTWVkIGV0IGFsLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g T3RoZXIgbml0cyAoYXMgd2VsbCBhcyAyIGZvbGxvd2luZyBzZWN0aW9ucykNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IE9MRDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIG9uZ29pbmctbWl0aWdhdGlv biB0ZWxlbWV0cnkgZGF0YSBmcm9tIHRoZSBET1RTIHNlcnZlci4NCj4gVGhlDQo+ID4gR0VUDQo+ ID4gPiA+ID4gICAgcmVxdWVzdCBzcGVjaWZ5IGEgJ3RtaWQnIChGaWd1cmUgMzEpIG9yIG5vdCAo RmlndXJlIDMyKS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE5FVzoNCj4gPiA+ID4gPg0KPiA+ID4g PiA+ICAgIG9uZ29pbmctbWl0aWdhdGlvbiB0ZWxlbWV0cnkgZGF0YSBmcm9tIHRoZSBET1RTIHNl cnZlci4NCj4gVGhlDQo+ID4gR0VUDQo+ID4gPiA+ID4gICAgcmVxdWVzdCBzcGVjaWZpZXMgYSAn dG1pZCcgKEZpZ3VyZSAzMSkgb3Igbm90IChGaWd1cmUgMzIpLg0KPiA+ID4gPiA+DQo+ID4gPiA+ DQo+ID4gPiA+IFtNZWRdIEZpeGVkLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+IERFTEVU RSAvdG0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IERvZXMgbm8gdG1pZD0gZGVsZXRlIGFsbCB0bWlk cyA/DQo+ID4gPiA+ID4gLSBJbiBwYXJ0aWN1bGFyIGFmdGVyIGEgcmVzdGFydCBvZiBhIGNsaWVu dD8NCj4gPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBbTWVkXSBZZXMsIHRoZXkgc2hvdWxkIGJl ICJkZWFjdGl2YXRlZCIuDQo+ID4gPiA+DQo+ID4gPiA+IE5FVzoNCj4gPiA+ID4gIlNlbmRpbmcg YSBERUxFVEUgd2l0aCBubyAndG1pZCcgaW5kaWNhdGVzIHRoYXQgYWxsICd0bWlkcycgbXVzdA0K PiA+IGJlDQo+ID4gPiA+IGRlYWN0aXZhdGVkLiINCj4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiAuLiBUaGUgYmVsb3cgaXMgY29taW5nIGZyb20gd2hhdCB0aGUgc2VydmVyIHNlbmRz IHRvIHRoZQ0KPiA+IGNsaWVudA0KPiA+ID4gPiA+IHBlcnNwZWN0aXZlLiAgSQ0KPiA+ID4gPiA+ ID4gYWNjZXB0IHRoYXQgaW4gdGhlIGNsaWVudCBzZW5kaW5nIHRvIHRoZSBzZXJ2ZXIgaGF2aW5n DQo+IHRhcmdldC0NCj4gPiA+ID4gPiBwcm90b2NvbCBhbmQNCj4gPiA+ID4gPiA+IHByb3RvY29s IG1heSBnaXZlIHJpc2UgdG8gc29tZSBwb3RlbnRpYWwgY29uZnVzaW9uLi4uDQo+ID4gPiA+ID4g Pg0KPiA+ID4gPg0KPiA+ID4gPiBbTWVkXSBMZXQncyBzZWUgaG93IHRvIGF2b2lkIHRoZSBpbmNv bnNpc3RlbmN5LiBUaGUgWUFORyBtb2R1bGUNCj4gaXMNCj4gPiA+ID4gY3VycmVudGx5IHJlZmxl Y3RpbmcgdGhlIHRleHQgd2UgaGF2ZSBJIGRyYWZ0LWlldGYtZG90cy0NCj4gdGVsZW1ldHJ5LQ0K PiA+ID4gPiAwNCNzZWN0aW9uLTcuMS4gV2UgbmVlZCB0byBjaGVjayB0aGF0IHNlY3Rpb24gdG8g c2VlIHdoZXJlIHRoZQ0KPiA+IHBlci0NCj4gPiA+ID4gdHJhbnNwb3J0IGlzIG1lbnRpb25lZCBh bmQgbWFrZSBzdXJlIHdlIGRvbid0IGJyZWFrIHRoaW5ncy4NCj4gPiA+ID4NCj4gPiA+ID4gRm9y IGV4YW1wbGUsIGlmIHByb3RvY29sIGlzIHByZXNlbnQgaW4gdGhlIHRhcmdldCwgd2UgdG8gYXZv aWQNCj4gPiA+ID4gY29uZmxpY3RpbmcgKGFuZCByZWR1bmRhbnQpIGluZm9ybWF0aW9uIHRvIGJl IHN1cHBsaWVkIGluIHRoZQ0KPiA+ID4gPiB0ZWxlbWV0cnkgZGF0YS4NCj4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSW4gdGVybXMgb2YgcHJvdG9jb2wsIHRoZXJlIGFyZSBz dGlsbCBzb21lIGNvbnNpc3RlbmNpZXMNCj4gPiBldmVuIGlmDQo+ID4gPiA+ID4geW91IGFjY2Vw dCB0aGUNCj4gPiA+ID4gPiA+ID4gYXJndW1lbnQgdGhhdCBwcm90b2NvbCBpcyBhbHJlYWR5IGRl ZmluZWQgaW4gdGhlDQo+IG1pdGlnYXRpb24NCj4gPiA+ID4gc2NvcGUNCj4gPiA+ID4gPiAod2hp Y2ggSSBhbQ0KPiA+ID4gPiA+ID4gPiBub3QgaGFwcHkgd2l0aCkuDQo+ID4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiA+IDEpIHRhcmdldC1wcm90b2NvbCBpcyBvcHRpb25hbGx5IHNldCBhbmQgaXQg aXMgYW4gYXJyYXkNCj4gPiB3aGVyZWFzDQo+ID4gPiA+ID4gcHJvdG9jb2wgaXMNCj4gPiA+ID4g PiA+IHNpbmd1bGFyDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IDIpIHByb3RvY29sIGlz IGRlZmluZWQgbWl0aWdhdGlvbiBzY29wZSBhdWdtZW50IGFzIHBlcg0KPiA+ID4gPiA+ID4gPiBt b2R1bGU6IGlldGYtZG90cy10ZWxlbWV0cnkNCj4gPiA+ID4gPiA+ID4gICBhdWdtZW50IC9pZXRm LXNpZ25hbDpkb3RzLXNpZ25hbC9pZXRmLXNpZ25hbDptZXNzYWdlLQ0KPiA+ID4gPiB0eXBlL2ll dGYtDQo+ID4gPiA+ID4gPiBzaWduYWw6bWl0aWdhdGlvbi0NCj4gPiA+ID4gPiA+ID4gc2NvcGUv aWV0Zi1zaWduYWw6c2NvcGU6DQo+ID4gPiA+ID4gPiA+ICAgICArLS1ybyB0b3RhbC10cmFmZmlj KiBbdW5pdCBwcm90b2NvbF0ge2RvdHMtdGVsZW1ldHJ5fT8NCj4gPiA+ID4gPiA+ID4gICAgIHwg ICstLXJvIHVuaXQgICAgICAgICAgICAgICAgIHVuaXQNCj4gPiA+ID4gPiA+ID4gICAgIHwgICst LXJvIHByb3RvY29sICAgICAgICAgICAgIHVpbnQ4DQo+ID4gPiA+ID4gPiA+ICAgICB8ICArLS1y byBsb3ctcGVyY2VudGlsZS1nPyAgICB5YW5nOmdhdWdlNjQNCj4gPiA+ID4gPiA+ID4gICAgIHwg ICstLXJvIG1pZC1wZXJjZW50aWxlLWc/ICAgIHlhbmc6Z2F1Z2U2NA0KPiA+ID4gPiA+ID4gPiAg ICAgfCAgKy0tcm8gaGlnaC1wZXJjZW50aWxlLWc/ICAgeWFuZzpnYXVnZTY0DQo+ID4gPiA+ID4g PiA+ICAgICB8ICArLS1ybyBwZWFrLWc/ICAgICAgICAgICAgICB5YW5nOmdhdWdlNjQNCj4gPiA+ ID4gPiA+ID4gICAgICstLXJ3IHRvdGFsLWF0dGFjay10cmFmZmljKiBbdW5pdF0ge2RvdHMtdGVs ZW1ldHJ5fT8NCj4gPiA+ID4gPiA+ID4gICAgIHwgICstLXJ3IHVuaXQgICAgICAgICAgICAgICAg IHVuaXQNCj4gPiA+ID4gPiA+ID4gICAgIHwgICstLXJ3IGxvdy1wZXJjZW50aWxlLWc/ICAgIHlh bmc6Z2F1Z2U2NA0KPiA+ID4gPiA+ID4gPiBBbmQgc28gdGhlcmUgaXMgbm8gY29uc2lzdGVuY3kg YmV0d2VlbiB0b3RhbC10cmFmZmljIGFuZA0KPiA+IHRvdGFsLQ0KPiA+ID4gPiA+IGF0dGFjay10 cmFmZmljDQo+ID4gPiA+DQo+ID4gPiA+IFtNZWRdIFRoZSBpZGVhIHdhcyB0byBoYXZlIGEgdmll dyBvZiB0b3RhbCB0cmFmZmljIGJvdW5kIHRvIGENCj4gPiB0YXJnZXQNCj4gPiA+ID4gcHJlZml4 L2RvbWFpbi4gV2Ugc2hvdWxkIGNsYXJpZnkgb3IgcmVtb3ZlIHRoZSBwcm90b2NvbCBmb3IgdGhp cw0KPiA+IG9uZS4NCj4gPiA+ID4gRmFpciBlbm91Z2guDQo+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiA+IDMpIEZvciAvdG0geW91IGhhdmUNCj4gPiA+ID4gPiA+ID4gICAgICst LToodGVsZW1ldHJ5KSB7ZG90cy10ZWxlbWV0cnl9Pw0KPiA+ID4gPiA+ID4gPiAgICAgICAgKy0t cncgcHJlLW9yLW9uZ29pbmctbWl0aWdhdGlvbiogW2N1aWQgdG1pZF0NCj4gPiA+ID4gPiA+ID4g Li4NCj4gPiA+ID4gPiA+ID4gICAgICAgICAgIHwgICstLXJ3IHRhcmdldC1wcm90b2NvbCogICAg IHVpbnQ4DQo+ID4gPiA+ID4gPiA+IC4uDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICArLS1ydyB0 b3RhbC10cmFmZmljKiBbdW5pdCBwcm90b2NvbF0NCj4gPiA+ID4gPiA+ID4gICAgICAgICAgIHwg ICstLXJ3IHVuaXQgICAgICAgICAgICAgICAgIHVuaXQNCj4gPiA+ID4gPiA+ID4gICAgICAgICAg IHwgICstLXJ3IHByb3RvY29sICAgICAgICAgICAgIHVpbnQ4DQo+ID4gPiA+ID4gPiA+IC4uDQo+ ID4gPiA+ID4gPiA+ICAgICAgICAgICArLS1ydyB0b3RhbC1hdHRhY2stdHJhZmZpYyogW3VuaXQg cHJvdG9jb2xdDQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICB8ICArLS1ydyB1bml0ICAgICAgICAg ICAgICAgICB1bml0DQo+ID4gPiA+ID4gPiA+ICAgICAgICAgICB8ICArLS1ydyBwcm90b2NvbCAg ICAgICAgICAgICB1aW50OA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBBbmQgc28gY291 bGQgYXJndWUgaGVyZSB0aGF0IHByb3RvY29sIGlzIG5vdCBuZWVkZWQNCj4gPiA+ID4NCj4gPiA+ ID4gW01lZF0gYnV0IHdlIG1heSBoYXZlIG1hbnkgcHJvdG9jb2xzIGxpc3RlZCB1bmRlciB0YXJn ZXQtDQo+IHByb3RvY29sLg0KPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA0 KSBJZiB0YXJnZXQtcHJvdG9jb2wgaXMgbm90IHNwZWNpZmllZCwgdGhlbiBpdCByZWZlcnMgdG8N Cj4gPiBhbnkNCj4gPiA+ID4gPiBwcm90b2NvbC4gIElmIHRhcmdldC0NCj4gPiA+ID4gPiA+ID4g cHJvdG9jb2wgaXMgbm90IGRlZmluZWQgaW4gL21pdGlnYXRlLCB0aGVuIEkgaGF2ZSBubyB3YXkN Cj4gb2YNCj4gPiA+ID4gPiBpbmRpY2F0aW5nIHdoaWNoIGlzIGENCj4gPiA+ID4gPiA+ID4gcHJv YmxlbWF0aWMgcHJvdG9jb2wgaWYgcHJvdG9jb2wgaXMgbm90IHN1cHBvcnRlZC4NCj4gPiA+ID4N Cj4gPiA+ID4gW01lZF0gR29vZCBwb2ludC4gVGhpcyBvbmUgKGFuZCB0aGUgZm9sbG93aW5nIG9u ZSkganVzdGlmaWVzDQo+IHRoYXQNCj4gPiB3ZQ0KPiA+ID4gPiBuZWVkIHRvIHJldmlzaXQgdGhl IGRlc2lnbi4NCj4gPiA+ID4NCj4gPiA+ID4gV2UgY2EgZ3JvdXAgdGhlIGRhdGEgYnkgdGFyZ2V0 LXByb3RvY29sIGFuZCBzZW5kIG1hbnkgdG1pZHMgaWYNCj4gPiBtYW55DQo+ID4gPiA+IHByb3Rv Y29scyBuZWVkIHRvIGJlIHJldHVybmVkLiBQcm90b2NvbCBjYW4gYmUgdGhlbiBvcHRpb25hbC4N Cj4gPiA+ID4NCj4gPiA+ID4gV291bGQgdGhhdCBiZSBiZXR0ZXI/DQo+ID4gPiA+DQo+ID4gPiA+ DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Fri Apr 3 04:51: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 5548A3A1842 for ; Fri, 3 Apr 2020 04:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 A2dRKetk3r-I for ; Fri, 3 Apr 2020 04:51:08 -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 AAF9F3A1847 for ; Fri, 3 Apr 2020 04:51:07 -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 1jKKqh-0002Ex-QI; Fri, 03 Apr 2020 12:50:59 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , "kaname nishizuka" , References: <158532456961.24330.9684049527965442282@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303148203F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0acd01d60458$9df439f0$d9dcadd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031482353@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0b7501d604f9$40fd53c0$c2f7fb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031483683@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0db001d606d0$3f6312b0$be293810$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031489524@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0ed901d6079d$ad34b1e0$079e15a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148B373@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <101201d60868$affd91a0$0ff8b4e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148D091@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <112b01d60927$b2ae7300$180b5900$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148D4EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148D71 C@OPEXCAUBMA2. corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148D71C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 3 Apr 2020 12:51:00 +0100 Message-ID: <11e001d609ae$2511c790$6f3556b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKpDKSlae91Qx1rveAaG4y93fawwwGS0CN0ActngzYBop/8/AGLlQYiAqtlZCwC5xXv2wJXxJ8rAWqlVlgB+pAcCQK0mLlyAOa0qGwBVbcNwQHQJXQlAokNMHal5+yX0A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 11:51:10 -0000 Hi Med, Thanks for this. It looks as if it might be going in the right = direction - I need to check if it can be sensibly coded up. Hi all, Some further thoughts. /tm =3D=3D=3D For /tm we are trying to use the same YANG model for 2 purposes. 1- Client indicating to Server attack telemetry information 2- Server indicating to Client attack telemetry information. With Server -> Client, this is initiated by GET. There is no reason as = to why Uri-Query: cannot be used for prefix=3D, port=3D, protocol=3D, = fqdn=3D, uri=3D, and alias-name=3D where each query can be repeated = multiple times and port=3D can be a range. Obviously the queries need = to be validated that they are valid for the client in the same way that = PUT gets validated. The GET response (and any Observed response) can then populate target as = appropriate and fill out the remaining information with non-zero values = (or certainly values of consequence). 1- For single port and/or single protocol in the query, do we just use = total-traffic, total-traffic-protocol or (missing) total-traffic-port = etc. in the response? 2- Same true for the other variants (e.g. total-attack-traffic) as = well. It may be that only total-traffic makes sense and total-traffic-protocol = can be dropped (same with other variants). There is nothing stopping = the Client doing different GET queries and observing all the different = query combinations (other than volumes of traffic). Then I believe that attack-detail should be an array [id] as multiple = attack vectors may be concurrent With Client -> Server, the information can easily be reduced by use of = target-* information in the PUT, so I again question whether = total-traffic-protocol etc. is really needed. Multiple PUTs can be done = with different target definitions which will not get caught by the = target overlapping rule. I am making a basic assumption that any traffic based information = portrayed in the PUT is kept by the DOTS server for its internal use, = but any GET responses reflect the actual situation, not a regurgitation = of what the Client sent the Server. It unclear to me what the difference is between embryonic and partial = connections. Embryonic is well defined, but partial is not. Can the = text be tidied up here? There is no notion of /tm refresh (as in /mitigate or /config refresh) - = is this correct? /mitigate =3D=3D=3D=3D=3D=3D=3D=3D The use of Queries would work here for any GET /mitigate (telemetry = extension) so that the responses can be controlled despite the target = definitions used for the PUT mitigation request. Again, (because of = packet size limitations when under attack) do we need = total-traffic-protocol etc.? The mitigate augment needs to be the same as for /tm from total-traffic = onwards (with the CBOR mapping including ietf-dots-telemetry:). If server-originated-telemetry is set and there is an active tmid, then = responses include telemetry information 1- Do the responses get sent out at telemetry-notify-interval intervals = (assuming Observe active)? 2- Why does this have to be with a tmid active - surely the tmid = response and telemetry response will be containing the same data?=20 /tm-setup =3D=3D=3D=3D=3D=3D=3D=3D When doing a GET with cuid=3D, but not tsid=3D (to get the max/min etc. = configuration information) what should be returned in the tsid field in = the response given that it is a key? While the baseline information is certainly worthwhile, things can = wildly fluctuate during, say, Black Friday sales, or sales for some = major festival. The baseline then really needs to be updated for when = these flash crowds take place to prevent unnecessary mitigation. The = text should be updated to reflect that there may be changing baselines. = - e.g. extra servers spun up to handle the additional expected loads. Peak Embryonic connection counts are a function of the listen queue = (backlog) sizes on the target server and are likely to be different per = port. I am not sure that over my time in the last 2 decades working = with DDoS that I have come across that many people who are able to = sensibly answer the embryonic max question - especially when SYN Cookies = and other techniques can muddy the water. There is benefit in reporting = it (e.g. SYN flooding attack) but I think it is difficult to baseline. = Thoughts? Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 03 April 2020 09:24 > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka > Cc: dots@ietf.org > Subject: Re: [Dots] New Version Notification for = draft-ietf-dots-telemetry-05.txt >=20 > Jon, >=20 > FWIW, the proposed change on the tree diagram can be seen here: >=20 > https://github.com/boucadair/draft-dots- > telemetry/commit/ea7c2101c4d3f748808c25fa85900fca7bca273b#diff- > 37c9ec7a9a8498c6dc3829deef79b5e7 >=20 > Of course, this is a proposal for discussion. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Dots [mailto:dots-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com > > Envoy=C3=A9 : vendredi 3 avril 2020 07:54 > > =C3=80 : Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka > > Cc : dots@ietf.org > > Objet : Re: [Dots] New Version Notification for draft-ietf-dots- > > telemetry-05.txt > > > > Hi Jon, > > > > Moving the discussion to the WG list as this is an important design > > change we need to make. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=C3=A9 : jeudi 2 avril 2020 21:49 > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; = kaname > > > nishizuka > > > Objet : RE: [Dots] New Version Notification for draft-ietf-dots- > > > telemetry-05.txt > > > > > > Stepping back to look at the bigger picture, I think that I would = be > > > more interested in the detail of a potentially multi-vectored > > mutating > > > attack, and so question whether having target-protocol as an = overall > > > restrictive view of all the detail makes sense. It is easier to > > > filter out data that I do not want / care about after receiving = it. > > > The remote peer may not have the same view of what to send v what = I > > am > > > interested in. > > > > > > [I am concerned about over-filling a packet and having to go into > > CoAP > > > Block2 mode though which will fail on a saturated link. I have = not > > > done any sizing of that yet with genuine attack information] > > > > > > So, for the /tm and /tm-setup stuff do we really need target- > > protocol > > > and could just have protocol as an optional, but array, entity? > > > > [Med] It is important to provide details per protocol as this will > > help identifying abnormal patterns. > > > > We could associate 0 to mean "all" protocols but I know this will = hurt > > many. We can consider the following change: > > > > OLD > > > > | +--rw baseline* [id] > > | +--rw id uint32 > > | +--rw target-prefix* inet:ip- > > prefix > > | +--rw target-port-range* [lower-port] > > | | +--rw lower-port inet:port-number > > | | +--rw upper-port? inet:port-number > > | +--rw target-protocol* uint8 > > | +--rw target-fqdn* = inet:domain- > > name > > | +--rw target-uri* inet:uri > > | +--rw total-traffic-normal-baseline* [unit > > protocol] > > | | +--rw unit unit > > | | +--rw protocol uint8 > > | | +--rw low-percentile-g? yang:gauge64 > > | | +--rw mid-percentile-g? yang:gauge64 > > | | +--rw high-percentile-g? yang:gauge64 > > | | +--rw peak-g? yang:gauge64 > > > > NEW: > > > > | +--:(baseline) > > | +--rw baseline* [id] > > | +--rw id uint32 > > | +--rw target-prefix* = inet:ip- > > prefix > > | +--rw target-port-range* [lower-port] > > | | +--rw lower-port inet:port-number > > | | +--rw upper-port? inet:port-number > > | +--rw target-protocol* uint8 > > | +--rw target-fqdn* > > inet:domain-name > > | +--rw target-uri* = inet:uri > > | +--rw alias-name* string > > | +--rw total-traffic-normal* [unit] > > | | +--rw unit unit > > | | +--rw low-percentile-g? yang:gauge64 > > | | +--rw mid-percentile-g? yang:gauge64 > > | | +--rw high-percentile-g? yang:gauge64 > > | | +--rw peak-g? yang:gauge64 > > | +--rw total-traffic-normal-per-protocol* [unit > > protocol] > > | | +--rw unit unit > > | | +--rw protocol uint8 > > | | +--rw low-percentile-g? yang:gauge64 > > | | +--rw mid-percentile-g? yang:gauge64 > > | | +--rw high-percentile-g? yang:gauge64 > > | | +--rw peak-g? yang:gauge64 > > > > Of course, the protocol must be listed in target-protocol (if > > present). > > > > > > > > Then for /mitigate, target-protocol is ignored in deciding what to > > > send back, but the use of an optional protocol array can reduce = some > > > of the packet size. > > > > > > total-attack-connection / total-connection-capacity will only be > > for > > > connection based connections - primarily TCP I suspect. > > > > [Med] Agree. > > > > However > > > (target) ports may be relevant here - a server may be able to > > support > > > X HTTPS connections, but only Y DNS (TCP) connections - or a load- > > > balancer in the path is only capable of handling Z connections - = no > > > matter what the port is.. So, do we want to introduce optional > > ports? > > > > [Med] These ports have to be listed in target-port-range (if = present). > > If we include port to the existing list, we can't maintain two = entries > > for the same protocol but with distinct port. It may be more simple = to > > make this change: > > > > OLD: > > | +--rw total-connection-capacity* [protocol] > > | +--rw protocol uint8 > > | +--rw connection? uint64 > > | +--rw connection-client? uint64 > > | +--rw embryonic? uint64 > > | +--rw embryonic-client? uint64 > > | +--rw connection-ps? uint64 > > | +--rw connection-client-ps? uint64 > > | +--rw request-ps? uint64 > > | +--rw request-client-ps? uint64 > > | +--rw partial-request-ps? uint64 > > | +--rw partial-request-client-ps? uint64 > > > > NEW: > > > > | +--rw total-connection-capacity* [protocol] > > | | +--rw protocol uint8 > > | | +--rw connection? uint64 > > | | +--rw connection-client? uint64 > > | | +--rw embryonic? uint64 > > | | +--rw embryonic-client? uint64 > > | | +--rw connection-ps? uint64 > > | | +--rw connection-client-ps? uint64 > > | | +--rw request-ps? uint64 > > | | +--rw request-client-ps? uint64 > > | | +--rw partial-request-ps? uint64 > > | | +--rw partial-request-client-ps? uint64 > > | +--rw total-connection-capacity-per-port* = [protocol > > lower-port] > > | +--rw protocol uint8 > > | +--rw lower-port inet:port- > > number > > | +--rw connection? uint64 > > | +--rw connection-client? uint64 > > | +--rw embryonic? uint64 > > | +--rw embryonic-client? uint64 > > | +--rw connection-ps? uint64 > > | +--rw connection-client-ps? uint64 > > | +--rw request-ps? uint64 > > | +--rw request-client-ps? uint64 > > | +--rw partial-request-ps? uint64 > > | +--rw partial-request-client-ps? uint64 > > > > > > > > > > NEW: > > > > > "Sending a DELETE with no 'tmid' indicates that all 'tmids' = must > > > be > > > > > deactivated." > > > > > > > > > > > I found this (but I prefer your addition for consistency) > > > > > > A DOTS client that lost the state of its active 'tmids' or has = to > > > set > > > 'tmid' back to zero (e.g., crash or restart) MUST send a GET > > > request > > > to the DOTS server to retrieve the list of active 'tmid'. The > > DOTS > > > client may then delete 'tmids' that should not be active = anymore. > > > > > > > [Med] Yes. The NEW text will be right after this one. > > > > > Other minor nits > > > > > > OLD > > > attack-severity: Attack severity. These values are supported: > > > Emergency (1), critical (2), and alert (3). > > > NEW (case of emergency) > > > attack-severity: Attack severity. These values are supported: > > > emergency (1), critical (2), and alert (3). > > > > > > OLD > > > tmid: Telemetry Identifier is an identifier for the DOTS = pre-or- > > > ongoing-mitigation telemetry data represented as an = integer. > > > This identifier MUST be generated by DOTS clients. 'tsid' > > > values > > > NEW tsid -> tmid > > > tmid: Telemetry Identifier is an identifier for the DOTS = pre-or- > > > ongoing-mitigation telemetry data represented as an = integer. > > > This identifier MUST be generated by DOTS clients. 'tmid' > > > values > > > > > > > [Med] Fixed. Thanks. > > > > > Regards > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: 02 April 2020 19:42 > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka > > > > Subject: RE: [Dots] New Version Notification for = draft-ietf-dots- > > > telemetry-05.txt > > > > > > > > Re-, > > > > > > > > The same issue applies as well for the baseline component: > > > > > > > > If we convey multiple protocols in target-prefix and want to > > signal > > > all total- > > > > traffic-normal-baseline + total-traffic-normal-baseline of each > > > protocol listed in > > > > target-prefix, we will need to have to use an index in addition = to > > > the unit. > > > > Protocol can then become optional. The same apply for total- > > > connection- > > > > capacity. > > > > > > > > I need to think about this further. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De : BOUCADAIR Mohamed TGI/OLN > > > > > Envoy=C3=A9 : jeudi 2 avril 2020 19:29 > > > > > =C3=80 : 'Jon Shallow'; Konda, Tirumaleswar Reddy; kaname = nishizuka > > > > > Objet : RE: [Dots] New Version Notification for = draft-ietf-dots- > > > > > telemetry-05.txt > > > > > > > > > > Hi Jon, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=C3=A9 : mercredi 1 avril 2020 23:01 > > > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar = Reddy; > > kaname > > > > > > nishizuka > > > > > > Objet : RE: [Dots] New Version Notification for draft-ietf- > > dots- > > > > > > telemetry-05.txt > > > > > > > > > > > > Hi Med et al, > > > > > > > > > > > > Other nits (as well as 2 following sections) > > > > > > > > > > > > OLD: > > > > > > > > > > > > ongoing-mitigation telemetry data from the DOTS server. > > The > > > GET > > > > > > request specify a 'tmid' (Figure 31) or not (Figure 32). > > > > > > > > > > > > NEW: > > > > > > > > > > > > ongoing-mitigation telemetry data from the DOTS server. > > The > > > GET > > > > > > request specifies a 'tmid' (Figure 31) or not (Figure = 32). > > > > > > > > > > > > > > > > [Med] Fixed. > > > > > > > > > > > > > > > > DELETE /tm > > > > > > > > > > > > Does no tmid=3D delete all tmids ? > > > > > > - In particular after a restart of a client? > > > > > > > > > > > > > > > > [Med] Yes, they should be "deactivated". > > > > > > > > > > NEW: > > > > > "Sending a DELETE with no 'tmid' indicates that all 'tmids' = must > > > be > > > > > deactivated." > > > > > > > > > > > > > > > > > > > .. The below is coming from what the server sends to the > > > client > > > > > > perspective. I > > > > > > > accept that in the client sending to the server having > > target- > > > > > > protocol and > > > > > > > protocol may give rise to some potential confusion... > > > > > > > > > > > > > > > > > [Med] Let's see how to avoid the inconsistency. The YANG = module > > is > > > > > currently reflecting the text we have I draft-ietf-dots- > > telemetry- > > > > > 04#section-7.1. We need to check that section to see where the > > > per- > > > > > transport is mentioned and make sure we don't break things. > > > > > > > > > > For example, if protocol is present in the target, we to avoid > > > > > conflicting (and redundant) information to be supplied in the > > > > > telemetry data. > > > > > > > > > > > > > > > > > > > > > In terms of protocol, there are still some consistencies > > > even if > > > > > > you accept the > > > > > > > > argument that protocol is already defined in the > > mitigation > > > > > scope > > > > > > (which I am > > > > > > > > not happy with). > > > > > > > > > > > > > > > > 1) target-protocol is optionally set and it is an array > > > whereas > > > > > > protocol is > > > > > > > singular > > > > > > > > > > > > > > > > 2) protocol is defined mitigation scope augment as per > > > > > > > > module: ietf-dots-telemetry > > > > > > > > augment /ietf-signal:dots-signal/ietf-signal:message- > > > > > type/ietf- > > > > > > > signal:mitigation- > > > > > > > > scope/ietf-signal:scope: > > > > > > > > +--ro total-traffic* [unit protocol] = {dots-telemetry}? > > > > > > > > | +--ro unit unit > > > > > > > > | +--ro protocol uint8 > > > > > > > > | +--ro low-percentile-g? yang:gauge64 > > > > > > > > | +--ro mid-percentile-g? yang:gauge64 > > > > > > > > | +--ro high-percentile-g? yang:gauge64 > > > > > > > > | +--ro peak-g? yang:gauge64 > > > > > > > > +--rw total-attack-traffic* [unit] {dots-telemetry}? > > > > > > > > | +--rw unit unit > > > > > > > > | +--rw low-percentile-g? yang:gauge64 > > > > > > > > And so there is no consistency between total-traffic and > > > total- > > > > > > attack-traffic > > > > > > > > > > [Med] The idea was to have a view of total traffic bound to a > > > target > > > > > prefix/domain. We should clarify or remove the protocol for = this > > > one. > > > > > Fair enough. > > > > > > > > > > > > > > > > > > > > > 3) For /tm you have > > > > > > > > +--:(telemetry) {dots-telemetry}? > > > > > > > > +--rw pre-or-ongoing-mitigation* [cuid tmid] > > > > > > > > .. > > > > > > > > | +--rw target-protocol* uint8 > > > > > > > > .. > > > > > > > > +--rw total-traffic* [unit protocol] > > > > > > > > | +--rw unit unit > > > > > > > > | +--rw protocol uint8 > > > > > > > > .. > > > > > > > > +--rw total-attack-traffic* [unit protocol] > > > > > > > > | +--rw unit unit > > > > > > > > | +--rw protocol uint8 > > > > > > > > > > > > > > > > And so could argue here that protocol is not needed > > > > > > > > > > [Med] but we may have many protocols listed under target- > > protocol. > > > > > > > > > > > > > > > > > > > > > 4) If target-protocol is not specified, then it refers = to > > > any > > > > > > protocol. If target- > > > > > > > > protocol is not defined in /mitigate, then I have no way > > of > > > > > > indicating which is a > > > > > > > > problematic protocol if protocol is not supported. > > > > > > > > > > [Med] Good point. This one (and the following one) justifies > > that > > > we > > > > > need to revisit the design. > > > > > > > > > > We ca group the data by target-protocol and send many tmids if > > > many > > > > > protocols need to be returned. Protocol can be then optional. > > > > > > > > > > Would that be better? > > > > > > > > > > > > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 3 06:27: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 874EA3A094F for ; Fri, 3 Apr 2020 06:27: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, 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 bxeztazGXRqA for ; Fri, 3 Apr 2020 06:27:11 -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 862B63A0885 for ; Fri, 3 Apr 2020 06:27:10 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 48v11n26T2z5vpK; Fri, 3 Apr 2020 15:27:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585920429; bh=VmioOamDvykECcDF0AMOvT+ZMn+XWye+QbdNSHVoWeg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=uWvs+NiHANfNQd7jBgZiDgsuY6n63hmAVVz68BYnbkS+TJO5eMArykZY7t3EAcuvO GBHhT1daHZ9LZ0fDuKFJvFVRQlXGJbZeOReAnODskZRUXmBN4XSonIQ+xYPwiFXT5A gtbY2pjTVus2xJmU7AL/DWZvZPuZqU7xHOvg6YfGvfaL788/sSIUScoHsgtZ8O2w9S vKLhVEwvjtVF4wHXQgzNN5qceOdCgG2mXNKlZo4yzOOWraDDtXChl30LbDZLYzJvJa iFZpNz/uYIQJ40ATMQeboDk0Q8IrcMMYJoS0l0ZwGtY4es3DN/D0CrAxkgitM5B7mg PBNg4EWpAQvTA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48v11n0s0bzCql2; Fri, 3 Apr 2020 15:27:09 +0200 (CEST) From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: /tm RE: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AdYJu5DRXLUtDkPSQTORdRmIDmDK/w== Date: Fri, 3 Apr 2020 13:27:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148DAD8@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] /tm RE: New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 13:27:13 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWll dGZAanBzaGFsbG93LmNvbV0NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAzIGF2cmlsIDIwMjAgMTM6 NTENCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeTsga2FuYW1lDQo+IG5pc2hpenVrYTsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBS RTogW0RvdHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kb3RzLQ0K PiB0ZWxlbWV0cnktMDUudHh0DQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBUaGFua3MgZm9yIHRoaXMu ICBJdCBsb29rcyBhcyBpZiBpdCBtaWdodCBiZSBnb2luZyBpbiB0aGUgcmlnaHQNCj4gZGlyZWN0 aW9uIC0gSSBuZWVkIHRvIGNoZWNrIGlmIGl0IGNhbiBiZSBzZW5zaWJseSBjb2RlZCB1cC4NCj4g DQoNCltNZWRdIEdyZWF0LCB0aGFua3MuIA0KDQo+IEhpIGFsbCwNCj4gDQo+IFNvbWUgZnVydGhl ciB0aG91Z2h0cy4NCj4gDQo+IC90bQ0KPiA9PT0NCj4gDQo+IEZvciAvdG0gd2UgYXJlIHRyeWlu ZyB0byB1c2UgdGhlIHNhbWUgWUFORyBtb2RlbCBmb3IgMiBwdXJwb3Nlcy4NCj4gMS0gIENsaWVu dCBpbmRpY2F0aW5nIHRvIFNlcnZlciBhdHRhY2sgdGVsZW1ldHJ5IGluZm9ybWF0aW9uDQo+IDIt IFNlcnZlciBpbmRpY2F0aW5nIHRvIENsaWVudCBhdHRhY2sgdGVsZW1ldHJ5IGluZm9ybWF0aW9u Lg0KPiANCj4gV2l0aCBTZXJ2ZXIgLT4gQ2xpZW50LCB0aGlzIGlzIGluaXRpYXRlZCBieSBHRVQu ICBUaGVyZSBpcyBubyByZWFzb24NCj4gYXMgdG8gd2h5IFVyaS1RdWVyeTogY2Fubm90IGJlIHVz ZWQgZm9yIHByZWZpeD0sIHBvcnQ9LCBwcm90b2NvbD0sDQo+IGZxZG49LCB1cmk9LCBhbmQgYWxp YXMtbmFtZT0gd2hlcmUgZWFjaCBxdWVyeSBjYW4gYmUgcmVwZWF0ZWQgbXVsdGlwbGUNCj4gdGlt ZXMgYW5kIHBvcnQ9IGNhbiBiZSBhIHJhbmdlLiAgT2J2aW91c2x5IHRoZSBxdWVyaWVzIG5lZWQg dG8gYmUNCj4gdmFsaWRhdGVkIHRoYXQgdGhleSBhcmUgdmFsaWQgZm9yIHRoZSBjbGllbnQgaW4g dGhlIHNhbWUgd2F5IHRoYXQgUFVUDQo+IGdldHMgdmFsaWRhdGVkLg0KPiANCj4gVGhlIEdFVCBy ZXNwb25zZSAoYW5kIGFueSBPYnNlcnZlZCByZXNwb25zZSkgY2FuIHRoZW4gcG9wdWxhdGUgdGFy Z2V0DQo+IGFzIGFwcHJvcHJpYXRlIGFuZCBmaWxsIG91dCB0aGUgcmVtYWluaW5nIGluZm9ybWF0 aW9uIHdpdGggbm9uLXplcm8NCj4gdmFsdWVzIChvciBjZXJ0YWlubHkgdmFsdWVzIG9mIGNvbnNl cXVlbmNlKS4NCj4gMS0gIEZvciBzaW5nbGUgcG9ydCBhbmQvb3Igc2luZ2xlIHByb3RvY29sIGlu IHRoZSBxdWVyeSwgZG8gd2UganVzdA0KPiB1c2UgdG90YWwtdHJhZmZpYywgdG90YWwtdHJhZmZp Yy1wcm90b2NvbCBvciAobWlzc2luZykgdG90YWwtdHJhZmZpYy0NCj4gcG9ydCBldGMuIGluIHRo ZSByZXNwb25zZT8NCg0KW01lZF0gdG90YWwtdHJhZmZpYyBzaG91bGQgYmUgc3VmZmljaWVudCwg dW5sZXNzIGEgbW9yZSBncmFudWxhcml0eSBpcyBhdmFpbGFibGUgc2luZ2xlIHBvcnQtbXVsdGlw bGUgcHJvdG9jb2xzLg0KDQo+IDItICBTYW1lIHRydWUgZm9yIHRoZSBvdGhlciB2YXJpYW50cyAo ZS5nLiB0b3RhbC1hdHRhY2stdHJhZmZpYykgYXMNCj4gd2VsbC4NCj4gSXQgbWF5IGJlIHRoYXQg b25seSB0b3RhbC10cmFmZmljIG1ha2VzIHNlbnNlIGFuZCB0b3RhbC10cmFmZmljLQ0KPiBwcm90 b2NvbCBjYW4gYmUgZHJvcHBlZCAoc2FtZSB3aXRoIG90aGVyIHZhcmlhbnRzKS4gIFRoZXJlIGlz IG5vdGhpbmcNCj4gc3RvcHBpbmcgdGhlIENsaWVudCBkb2luZyBkaWZmZXJlbnQgR0VUIHF1ZXJp ZXMgYW5kIG9ic2VydmluZyBhbGwgdGhlDQo+IGRpZmZlcmVudCBxdWVyeSBjb21iaW5hdGlvbnMg KG90aGVyIHRoYW4gdm9sdW1lcyBvZiB0cmFmZmljKS4NCg0KW01lZF0gSW5kZWVkLiBUaGUgY3Vy cmVudCBtb2RlbCBpcyBmbGV4aWJsZTogeW91IG1heSBjb25zdW1lIG9uZSB0bWlkIG9yIHVzZSBh cyBtYW55IHlvdSB3YW50LiANCg0KPiANCj4gVGhlbiBJIGJlbGlldmUgdGhhdCBhdHRhY2stZGV0 YWlsIHNob3VsZCBiZSBhbiBhcnJheSBbaWRdIGFzIG11bHRpcGxlDQo+IGF0dGFjayB2ZWN0b3Jz IG1heSBiZSBjb25jdXJyZW50DQoNCg0KW01lZF0gSSBndWVzcyB5b3UgbWVhbiBhdHRhY2staWQu IFRoYXQncyB3b3VsZCBiZSBPSy4NCg0KPiANCj4gV2l0aCBDbGllbnQgLT4gU2VydmVyLCB0aGUg aW5mb3JtYXRpb24gY2FuIGVhc2lseSBiZSByZWR1Y2VkIGJ5IHVzZSBvZg0KPiB0YXJnZXQtKiBp bmZvcm1hdGlvbiBpbiB0aGUgUFVULCBzbyBJIGFnYWluIHF1ZXN0aW9uIHdoZXRoZXIgdG90YWwt DQo+IHRyYWZmaWMtcHJvdG9jb2wgZXRjLiBpcyByZWFsbHkgbmVlZGVkLg0KDQpbTWVkXSBUaGVz ZSBhcmUgbm90IG1hbmRhdG9yeS4gSXQgZGVwZW5kcyBvbiB3aGF0IHRoZSBjbGllbnRzIHB1dCBp biB0aGUgcmVxdWVzdChzKS4gDQoNCiAgTXVsdGlwbGUgUFVUcyBjYW4gYmUgZG9uZQ0KPiB3aXRo IGRpZmZlcmVudCB0YXJnZXQgZGVmaW5pdGlvbnMgd2hpY2ggd2lsbCBub3QgZ2V0IGNhdWdodCBi eSB0aGUNCj4gdGFyZ2V0IG92ZXJsYXBwaW5nIHJ1bGUuDQoNCltNZWRdIEFncmVlLiAgDQoNCj4g DQo+IEkgYW0gbWFraW5nIGEgYmFzaWMgYXNzdW1wdGlvbiB0aGF0IGFueSB0cmFmZmljIGJhc2Vk IGluZm9ybWF0aW9uDQo+IHBvcnRyYXllZCBpbiB0aGUgUFVUIGlzIGtlcHQgYnkgdGhlIERPVFMg c2VydmVyIGZvciBpdHMgaW50ZXJuYWwgdXNlLA0KPiBidXQgYW55IEdFVCByZXNwb25zZXMgcmVm bGVjdCB0aGUgYWN0dWFsIHNpdHVhdGlvbiwgbm90IGENCj4gcmVndXJnaXRhdGlvbiBvZiB3aGF0 IHRoZSBDbGllbnQgc2VudCB0aGUgU2VydmVyLg0KPiANCj4gSXQgdW5jbGVhciB0byBtZSB3aGF0 IHRoZSBkaWZmZXJlbmNlIGlzIGJldHdlZW4gZW1icnlvbmljIGFuZCBwYXJ0aWFsDQo+IGNvbm5l Y3Rpb25zLiAgRW1icnlvbmljIGlzIHdlbGwgZGVmaW5lZCwgYnV0IHBhcnRpYWwgaXMgbm90LiAg Q2FuIHRoZQ0KPiB0ZXh0IGJlIHRpZGllZCB1cCBoZXJlPw0KDQpbTWVkXSBUaGVzZSBtYXkgc2Vl bSB0byBoYXZlIHNpbWlsYXJpdGllcywgYnV0IHdlIHdhbnRlZCB0byBjb3ZlciBwcm90b2NvbHMg c3VjaCBhcyBRVUlDIHRoYXQgY2FuIGJlIHN1YmplY3RlZCB0byBwYXJ0aWFsIHJlcXVlc3QgYXR0 YWNrcywgYnV0IG5vdCBlbWJyeW9uaWMgb25lcy4gQWdyZWUgdGhhdCB3ZSBuZWVkIHRvIGNsYXJp ZnkgdGhpcyBmdXJ0aGVyIGluIHRoZSBkcmFmdC4gDQoNCj4gDQo+IFRoZXJlIGlzIG5vIG5vdGlv biBvZiAvdG0gcmVmcmVzaCAoYXMgaW4gL21pdGlnYXRlIG9yIC9jb25maWcgcmVmcmVzaCkNCj4g LSBpcyB0aGlzIGNvcnJlY3Q/DQoNCltNZWRdIEl0IGlzIHVwIHRvIHRoZSBhZ2VudHMgdG8gbWFp bnRhaW4gdGhlaXIgdG1pZHMgYWN0aXZlIG9yIG5vOg0KDQogICBIb3cgbG9uZyBhIERPVFMgc2Vy dmVyIG1haW50YWlucyBhICd0bWlkJyBhcyBhY3RpdmUgb3IgbG9ncyB0aGUNCiAgIGVuY2xvc2Vk IHRlbGVtZXRyeSBpbmZvcm1hdGlvbiBpcyBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4NCg0KDQo= From nobody Fri Apr 3 06:39:26 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 2903C3A1496 for ; Fri, 3 Apr 2020 06:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_LOW=-0.7, 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 AHTno0eDPKNI for ; Fri, 3 Apr 2020 06:39:23 -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 3CAB43A140D for ; Fri, 3 Apr 2020 06:39:23 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 48v1Hs2TWtzCrNb; Fri, 3 Apr 2020 15:39:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585921161; bh=CBkg7huXZ3MsZQBndvh6vfZ0HVR5AhWtkp5b2O2vNlo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IxVreAALxjFOnnLnrsxkEix3AGPTcJBwSAHm+3Q/nlWeT/kGQASUxEraxgD0zjqxh QXeqczEIkYKCDXx21cyih1Si8u07cpw77YEPQzQlLznLa7YUivjzg1+iMgfr/cvD1w IoAIe0Vbwvnq16TMtD5vvKf8fi+XEGpbFtt5+28vQugqm25iG1rWxQaNOIcU8srVjw tgId+6dD0osBSH27ayai4a/t8ii5Br2SYSkHx5j+p3a418q/ot6LB5k7zKuJ2sHzHw Yr932NIcyojCYOL61Xs5LIseeKnM5vW45Icmq5o4EuqZN8tbGUsU0lYZ8xkYtfolSV w0owSuLFc+v+g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 48v1Hs1w8XzFpWb; Fri, 3 Apr 2020 15:39:21 +0200 (CEST) From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: /mitigate RE: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AdYJvUag7LcAa5LQREq4FwktkaLs+w== Date: Fri, 3 Apr 2020 13:39:20 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148DB22@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] /mitigate RE: New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 13:39:25 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1p ZXRmQGpwc2hhbGxvdy5jb21dDQo+IEVudm95w6nCoDogdmVuZHJlZGkgMyBhdnJpbCAyMDIwIDEz OjUxDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHk7IGthbmFtZQ0KPiBuaXNoaXp1a2E7IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDog UkU6IFtEb3RzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90cy0N Cj4gdGVsZW1ldHJ5LTA1LnR4dA0KPiANCj4gSGkgTWVkLA0KPiANCj4gVGhhbmtzIGZvciB0aGlz LiAgSXQgbG9va3MgYXMgaWYgaXQgbWlnaHQgYmUgZ29pbmcgaW4gdGhlIHJpZ2h0DQo+IGRpcmVj dGlvbiAtIEkgbmVlZCB0byBjaGVjayBpZiBpdCBjYW4gYmUgc2Vuc2libHkgY29kZWQgdXAuDQo+ IA0KPiANCj4gL21pdGlnYXRlDQo+ID09PT09PT09DQo+IA0KPiBUaGUgdXNlIG9mIFF1ZXJpZXMg d291bGQgd29yayBoZXJlIGZvciBhbnkgR0VUIC9taXRpZ2F0ZSAodGVsZW1ldHJ5DQo+IGV4dGVu c2lvbikgc28gdGhhdCB0aGUgcmVzcG9uc2VzIGNhbiBiZSBjb250cm9sbGVkIGRlc3BpdGUgdGhl IHRhcmdldA0KPiBkZWZpbml0aW9ucyB1c2VkIGZvciB0aGUgUFVUIG1pdGlnYXRpb24gcmVxdWVz dC4gIEFnYWluLCAoYmVjYXVzZSBvZg0KPiBwYWNrZXQgc2l6ZSBsaW1pdGF0aW9ucyB3aGVuIHVu ZGVyIGF0dGFjaykgZG8gd2UgbmVlZCB0b3RhbC10cmFmZmljLQ0KPiBwcm90b2NvbCBldGMuPw0K DQpbTWVkXSBPbmx5IGFnZ3JlZ2F0ZXMgYXJlIHNlbnQgdG8gYXZvaWQgZnJhZ21lbnRhdGlvbi4g DQoNCj4gDQo+IFRoZSBtaXRpZ2F0ZSBhdWdtZW50IG5lZWRzIHRvIGJlIHRoZSBzYW1lIGFzIGZv ciAvdG0gZnJvbSB0b3RhbC0NCj4gdHJhZmZpYyBvbndhcmRzICh3aXRoIHRoZSBDQk9SIG1hcHBp bmcgaW5jbHVkaW5nIGlldGYtZG90cy0NCj4gdGVsZW1ldHJ5OikuDQoNCltNZWRdIHllcy4NCg0K PiANCj4gSWYgc2VydmVyLW9yaWdpbmF0ZWQtdGVsZW1ldHJ5IGlzIHNldCBhbmQgdGhlcmUgaXMg YW4gYWN0aXZlIHRtaWQsDQo+IHRoZW4gcmVzcG9uc2VzIGluY2x1ZGUgdGVsZW1ldHJ5IGluZm9y bWF0aW9uDQo+IDEtIERvIHRoZSByZXNwb25zZXMgZ2V0IHNlbnQgb3V0IGF0IHRlbGVtZXRyeS1u b3RpZnktaW50ZXJ2YWwNCj4gaW50ZXJ2YWxzIChhc3N1bWluZyBPYnNlcnZlIGFjdGl2ZSk/DQoN CltNZWRdIE5vLCB0ZWxlbWV0cnktbm90aWZ5LWludGVydmFsIHNldHMgdGhlIG1pbmltdW0gdG8g YmUgcmVzcGVjdGVkIHRvIGF2b2lkIG92ZXJsb2FkaW5nIHRoZSBwZWVyIHdpdGggdGVsZW1ldHJ5 IHVwZGF0ZXMuIA0KDQo+IDItIFdoeSBkb2VzIHRoaXMgaGF2ZSB0byBiZSB3aXRoIGEgdG1pZCBh Y3RpdmUgLSBzdXJlbHkgdGhlIHRtaWQNCj4gcmVzcG9uc2UgYW5kIHRlbGVtZXRyeSByZXNwb25z ZSB3aWxsIGJlIGNvbnRhaW5pbmcgdGhlIHNhbWUgZGF0YT8NCj4gDQoNCltNZWRdIEFyZSB5b3Ug cmVmZXJyaW5nIHRvIHRoZSBmb2xsb3dpbmc6DQoNCiAgIEluIG9yZGVyIHRvIG1ha2UgdXNlIG9m IHRoaXMgZmVhdHVyZSwgRE9UUyBjbGllbnRzIE1VU1QgZXN0YWJsaXNoIGENCiAgIHRlbGVtZXRy eSBzZXR1cCBzZXNzaW9uIHdpdGggdGhlIERPVFMgc2VydmVyIGluICdpZGxlJyB0aW1lIGFuZCBN VVNUDQogICBzZXQgdGhlICdzZXJ2ZXItb3JpZ2luYXRlZC10ZWxlbWV0cnknIGF0dHJpYnV0ZSB0 byAndHJ1ZQ0KDQpUaGlzIGlzIG5vdCBhYm91dCBoYXZpbmcgYSB0bWlkIGFjdGl2ZSwgYnV0IGNv bmZpZ3VyaW5nIHRoZSBzdXBwb3J0IG9mIHRlbGVtZXRyeSBub3RpZmljYXRpb24gdG8gYXZvaWQg ZXJyb3JzIGR1cmluZyBtaXRpZ2F0aW9uLg0K From nobody Fri Apr 3 06:48: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 3D0713A03FF for ; Fri, 3 Apr 2020 06:48:57 -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, 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 gvhpxD71Oxtf for ; Fri, 3 Apr 2020 06:48:53 -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 D98123A03EC for ; Fri, 3 Apr 2020 06:48:52 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 48v1Vq213rz2xrk; Fri, 3 Apr 2020 15:48:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585921731; bh=R/UH1d/Y8HggDSJS0vxoSjOFtGWlsqPgYddOYumnA9Q=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=DTkXBcBGgzcOUVluv9WGM1CA2+lKtn9OlMLm0pUdimbtmXFmRXXjKplU8ZuWHbfT6 GC9OFgrNo3FG+Moc3gbH4Y/vnCkHi8poaiWwOg4FnJpg2nx4bafwAM922BAEEsPGl/ BIi+LxqfF614WCMPRGP8yp3DBA6z6eBMcPWkj8cqX8Md83nSCBYnh51p5VUZEm3WQk PZOnWNYVGveOGz4cJdrBKUCQFRq6bQYYyOooaYEOqMO/JcWWAkSJaaEIyNSfVF/sQ6 9Y4AAVHzBMG4C4vcCflD9MIUKoYxC9U6+U5ihujh5QUR7iZDTVX7f2ucpxRcCgft4/ L0F9FYXAyLPbw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 48v1Vq0vBxz2xC9; Fri, 3 Apr 2020 15:48:51 +0200 (CEST) From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: /tm-setup RE: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AdYJvpp41JiuyHdTTsKLbVcBs0zAdg== Date: Fri, 3 Apr 2020 13:48:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148DB3D@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 13:48:57 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1p ZXRmQGpwc2hhbGxvdy5jb21dDQo+IEVudm95w6nCoDogdmVuZHJlZGkgMyBhdnJpbCAyMDIwIDEz OjUxDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHk7IGthbmFtZQ0KPiBuaXNoaXp1a2E7IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDog UkU6IFtEb3RzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90cy0N Cj4gdGVsZW1ldHJ5LTA1LnR4dA0KPiANCj4gSGkgTWVkLA0KPiANCj4gVGhhbmtzIGZvciB0aGlz LiAgSXQgbG9va3MgYXMgaWYgaXQgbWlnaHQgYmUgZ29pbmcgaW4gdGhlIHJpZ2h0DQo+IGRpcmVj dGlvbiAtIEkgbmVlZCB0byBjaGVjayBpZiBpdCBjYW4gYmUgc2Vuc2libHkgY29kZWQgdXAuDQo+ IA0KPiBIaSBhbGwsDQo+IA0KPiBTb21lIGZ1cnRoZXIgdGhvdWdodHMuDQo+IA0KPiANCj4gL3Rt LXNldHVwDQo+ID09PT09PT09DQo+IA0KPiBXaGVuIGRvaW5nIGEgR0VUIHdpdGggY3VpZD0sIGJ1 dCBub3QgdHNpZD0gKHRvIGdldCB0aGUgbWF4L21pbiBldGMuDQo+IGNvbmZpZ3VyYXRpb24gaW5m b3JtYXRpb24pIHdoYXQgc2hvdWxkIGJlIHJldHVybmVkIGluIHRoZSB0c2lkIGZpZWxkDQo+IGlu IHRoZSByZXNwb25zZSBnaXZlbiB0aGF0IGl0IGlzIGEga2V5Pw0KDQpbTWVkXSBHb29kIGNhdGNo LiBUaGlzIG9uZSBoYXMgdG8gYmUgZml4ZWQuIA0KDQo+IA0KPiBXaGlsZSB0aGUgYmFzZWxpbmUg aW5mb3JtYXRpb24gaXMgY2VydGFpbmx5IHdvcnRod2hpbGUsIHRoaW5ncyBjYW4NCj4gd2lsZGx5 IGZsdWN0dWF0ZSBkdXJpbmcsIHNheSwgQmxhY2sgRnJpZGF5IHNhbGVzLCBvciBzYWxlcyBmb3Ig c29tZQ0KPiBtYWpvciBmZXN0aXZhbC4gIFRoZSBiYXNlbGluZSB0aGVuIHJlYWxseSBuZWVkcyB0 byBiZSB1cGRhdGVkIGZvciB3aGVuDQo+IHRoZXNlIGZsYXNoIGNyb3dkcyB0YWtlIHBsYWNlIHRv IHByZXZlbnQgdW5uZWNlc3NhcnkgbWl0aWdhdGlvbi4gIFRoZQ0KPiB0ZXh0IHNob3VsZCBiZSB1 cGRhdGVkIHRvIHJlZmxlY3QgdGhhdCB0aGVyZSBtYXkgYmUgY2hhbmdpbmcNCj4gYmFzZWxpbmVz LiAtIGUuZy4gZXh0cmEgc2VydmVycyBzcHVuIHVwIHRvIGhhbmRsZSB0aGUgYWRkaXRpb25hbA0K PiBleHBlY3RlZCBsb2Fkcy4NCg0KW01lZF0gR29vZCBwb2ludC4gDQoNCj4gDQo+IFBlYWsgRW1i cnlvbmljIGNvbm5lY3Rpb24gY291bnRzIGFyZSBhIGZ1bmN0aW9uIG9mIHRoZSBsaXN0ZW4gcXVl dWUNCj4gKGJhY2tsb2cpIHNpemVzIG9uIHRoZSB0YXJnZXQgc2VydmVyIGFuZCBhcmUgbGlrZWx5 IHRvIGJlIGRpZmZlcmVudA0KPiBwZXIgcG9ydC4gIEkgYW0gbm90IHN1cmUgdGhhdCBvdmVyIG15 IHRpbWUgaW4gdGhlIGxhc3QgMiBkZWNhZGVzDQo+IHdvcmtpbmcgd2l0aCBERG9TIHRoYXQgSSBo YXZlIGNvbWUgYWNyb3NzIHRoYXQgbWFueSBwZW9wbGUgd2hvIGFyZQ0KPiBhYmxlIHRvIHNlbnNp Ymx5IGFuc3dlciB0aGUgZW1icnlvbmljIG1heCBxdWVzdGlvbiAtIGVzcGVjaWFsbHkgd2hlbg0K PiBTWU4gQ29va2llcyBhbmQgb3RoZXIgdGVjaG5pcXVlcyBjYW4gbXVkZHkgdGhlIHdhdGVyLiAg VGhlcmUgaXMNCj4gYmVuZWZpdCBpbiByZXBvcnRpbmcgaXQgKGUuZy4gU1lOIGZsb29kaW5nIGF0 dGFjaykgYnV0IEkgdGhpbmsgaXQgaXMNCj4gZGlmZmljdWx0IHRvIGJhc2VsaW5lLiAgVGhvdWdo dHM/DQo+IA0KDQpbTWVkXSBUaGlzIGlzIGEgZmFpciBvYnNlcnZhdGlvbi4gV2Ugd2FudGVkIHRv IHNoYXJlIGFueSBpbmZvcm1hdGlvbiB0aGF0IG1pZ2h0IGJlIGF2YWlsYWJsZSB0byBoZWxwIGRl dGVjdCBhYm5vcm1hbCBwYXR0ZXJucy4gVGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQgYWxsIHRoZXNl IGl0ZW1zIG5lZWQgdG8gYmUgcHJlc2VudC4gSSdkIGxpa2UgdG8gaGVhciBtb3JlIGZyb20gdGhl IGdyb3VwLg0KDQoNCg== From nobody Fri Apr 3 07:06:31 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 A98483A0873 for ; Fri, 3 Apr 2020 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t7iiZA7Zg5Yc for ; Fri, 3 Apr 2020 07:06:25 -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 C86D43A0822 for ; Fri, 3 Apr 2020 07:06:24 -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 1jKMxf-0002Jk-Gf; Fri, 03 Apr 2020 15:06:19 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148DAD8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148DAD8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 3 Apr 2020 15:06:20 +0100 Message-ID: <120301d609c1$0cbd77d0$26386770$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLadwGu/+DxzrPPWtcp112B6IRg/qZekCBg Content-Language: en-gb Archived-At: Subject: Re: [Dots] /tm RE: New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 14:06:30 -0000 Hi Med et all, Please see inline Jon> Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 03 April 2020 14:27 > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; = dots@ietf.org > Subject: [Dots] /tm RE: New Version Notification for = draft-ietf-dots-telemetry- > 05.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=C3=A9 : vendredi 3 avril 2020 13:51 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; = kaname > > nishizuka; dots@ietf.org > > Objet : RE: [Dots] New Version Notification for draft-ietf-dots- > > telemetry-05.txt > > > > Hi Med, > > > > Thanks for this. It looks as if it might be going in the right > > direction - I need to check if it can be sensibly coded up. > > >=20 > [Med] Great, thanks. >=20 > > Hi all, > > > > Some further thoughts. > > > > /tm > > =3D=3D=3D > > > > For /tm we are trying to use the same YANG model for 2 purposes. > > 1- Client indicating to Server attack telemetry information > > 2- Server indicating to Client attack telemetry information. > > > > With Server -> Client, this is initiated by GET. There is no reason > > as to why Uri-Query: cannot be used for prefix=3D, port=3D, = protocol=3D, > > fqdn=3D, uri=3D, and alias-name=3D where each query can be repeated = multiple > > times and port=3D can be a range. Obviously the queries need to be > > validated that they are valid for the client in the same way that = PUT > > gets validated. Jon> What do you think about using Uri-Query: ? > > > > The GET response (and any Observed response) can then populate = target > > as appropriate and fill out the remaining information with non-zero > > values (or certainly values of consequence). > > 1- For single port and/or single protocol in the query, do we just > > use total-traffic, total-traffic-protocol or (missing) = total-traffic- > > port etc. in the response? >=20 > [Med] total-traffic should be sufficient, unless a more granularity is = available > single port-multiple protocols. Jon> OK. Jon> I think then that it needs to be stated that "total-traffic" is = filtered by whatever is in "target", which in turn is generated from any = Uri-Query: rather than what was used in the PUT (unless there are no = URI-Query:). It maybe that the GET URI-Query: list is constrained by = the PUT for that tmid.=20 Jon> That then raises the question as to what is returned for a GET with = no tmid=3D - currently all the tmids are returned, but should they be = further filtered by Uri-Query;? >=20 > > 2- Same true for the other variants (e.g. total-attack-traffic) as > > well. > > It may be that only total-traffic makes sense and total-traffic- > > protocol can be dropped (same with other variants). There is = nothing > > stopping the Client doing different GET queries and observing all = the > > different query combinations (other than volumes of traffic). >=20 > [Med] Indeed. The current model is flexible: you may consume one tmid = or use > as many you want. >=20 > > > > Then I believe that attack-detail should be an array [id] as = multiple > > attack vectors may be concurrent >=20 >=20 > [Med] I guess you mean attack-id. That's would be OK. >=20 Jon> Correct - attack-id. > > > > With Client -> Server, the information can easily be reduced by use = of > > target-* information in the PUT, so I again question whether total- > > traffic-protocol etc. is really needed. >=20 > [Med] These are not mandatory. It depends on what the clients put in = the > request(s). Jon> Again, as there have to be target definitions, what does = "total-traffic" refer to - need clarity in the text as to whether the is = overall traffic, or traffic as filtered by the target definition(s). >=20 > Multiple PUTs can be done > > with different target definitions which will not get caught by the > > target overlapping rule. >=20 > [Med] Agree. >=20 > > > > I am making a basic assumption that any traffic based information > > portrayed in the PUT is kept by the DOTS server for its internal = use, > > but any GET responses reflect the actual situation, not a > > regurgitation of what the Client sent the Server. > > > > It unclear to me what the difference is between embryonic and = partial > > connections. Embryonic is well defined, but partial is not. Can = the > > text be tidied up here? >=20 > [Med] These may seem to have similarities, but we wanted to cover = protocols > such as QUIC that can be subjected to partial request attacks, but not = embryonic > ones. Agree that we need to clarify this further in the draft. >=20 > > > > There is no notion of /tm refresh (as in /mitigate or /config = refresh) > > - is this correct? >=20 > [Med] It is up to the agents to maintain their tmids active or no: >=20 > How long a DOTS server maintains a 'tmid' as active or logs the > enclosed telemetry information is implementation-specific. Jon> I can work with that, I was just thinking about consistency with = the way things are done in the signal and data channels. ~Jon >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 3 07:17: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 4EA133A152C for ; Fri, 3 Apr 2020 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QYZIY36oCrI3 for ; Fri, 3 Apr 2020 07:17:04 -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 0E8323A1668 for ; Fri, 3 Apr 2020 07:17:03 -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 1jKN81-0002KA-MB; Fri, 03 Apr 2020 15:17:01 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148DB22@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148DB22@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 3 Apr 2020 15:17:02 +0100 Message-ID: <120801d609c2$8b7f75e0$a27e61a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG/SSTF4KileIDdUMOGUQth6qzRLKiU6t3Q Content-Language: en-gb Archived-At: Subject: Re: [Dots] /mitigate RE: New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 14:17:13 -0000 Hi Med, See inline Jon> Regards Jon > -----Original Message----- > From: Dots [mailto: bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 03 April 2020 14:39 > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; = dots@ietf.org > Subject: [Dots] /mitigate RE: New Version Notification for = draft-ietf-dots- > telemetry-05.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=C3=A9 : vendredi 3 avril 2020 13:51 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; = kaname > > nishizuka; dots@ietf.org > > Objet : RE: [Dots] New Version Notification for draft-ietf-dots- > > telemetry-05.txt > > > > Hi Med, > > > > Thanks for this. It looks as if it might be going in the right > > direction - I need to check if it can be sensibly coded up. > > > > > > /mitigate > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > The use of Queries would work here for any GET /mitigate (telemetry > > extension) so that the responses can be controlled despite the = target > > definitions used for the PUT mitigation request. Again, (because of > > packet size limitations when under attack) do we need total-traffic- > > protocol etc.? >=20 > [Med] Only aggregates are sent to avoid fragmentation. Jon> What about the use of Uri-Queries to filter on what is returned for = a GET? >=20 > > > > The mitigate augment needs to be the same as for /tm from total- > > traffic onwards (with the CBOR mapping including ietf-dots- > > telemetry:). >=20 > [Med] yes. >=20 > > > > If server-originated-telemetry is set and there is an active tmid, > > then responses include telemetry information > > 1- Do the responses get sent out at telemetry-notify-interval > > intervals (assuming Observe active)? >=20 > [Med] No, telemetry-notify-interval sets the minimum to be respected = to avoid > overloading the peer with telemetry updates. Jon> Hmm - OK. So we continue with whatever the signal channel logic = thinks is appropriate which is implementation independent as per Due to the higher likelihood of packet loss during a DDoS attack, the DOTS server periodically sends attack mitigation status to the DOTS client and also notifies the DOTS client whenever the status of the attack mitigation changes. If the DOTS server cannot maintain an RTT estimate, it MUST NOT send more than one asynchronous notification every 3 seconds, and SHOULD use an even less aggressive rate whenever possible (case 2 in Section 3.1.3 of [RFC8085]). >=20 > > 2- Why does this have to be with a tmid active - surely the tmid > > response and telemetry response will be containing the same data? > > >=20 > [Med] Are you referring to the following: >=20 > In order to make use of this feature, DOTS clients MUST establish a > telemetry setup session with the DOTS server in 'idle' time and = MUST > set the 'server-originated-telemetry' attribute to 'true >=20 > This is not about having a tmid active, but configuring the support of = telemetry > notification to avoid errors during mitigation. Jon> You are correct - this is the reference, but I had misread it. ~Jon > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 3 11:59:34 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 6F56F3A0B16 for ; Fri, 3 Apr 2020 11:59:31 -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, 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 2T8wFDLoG4jb for ; Fri, 3 Apr 2020 11:59:30 -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 C4BA33A0B14 for ; Fri, 3 Apr 2020 11:59:29 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr27.francetelecom.fr (ESMTP service) with ESMTPS id 48v8PC6TW7z4wfS; Fri, 3 Apr 2020 20:59:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585940367; bh=l6ayvVHEJvV++DzYr1fG2nP4051oVRfyOz676RXf8zQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ssESxhL9y+h0OOHlATQ79VXLs4GIKs0SQXFyE/N+GWD3AklqDrE9O40tlDfmsgPG4 eyrL03CwV7FfPHI+/6ALGS6nMjRzDPSszCA47O3/s+f8AJLCtpaz3XZ0mx1x4NBysa ABdmfbH7QBHH1+ZiXx7oT+g8H/UIY2ehNQQ/SrLpkHeHTOourIkknFAj3CpeJFqAb0 E6cVv5u372CJVxk1wlZt7Dg7sslaaSowspMKcs6WAYJp1Kik5Ia8ok+6BPRz8vwTDl GYM+0CugW5KOSVX+58xB/JEyG3B40xoPcwMCQCgcD9Wle6udhpx5x3oVsCIACf9Mm6 MYVDqpwEb2YeA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 48v8PC5Mw3zDq7v; Fri, 3 Apr 2020 20:59:27 +0200 (CEST) From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AdYJvpp41JiuyHdTTsKLbVcBs0zAdgAKyHRg Date: Fri, 3 Apr 2020 18:59:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148DB3D@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 18:59:32 -0000 Sm9uLCANCg0KDQo+ID4NCj4gPiAvdG0tc2V0dXANCj4gPiA9PT09PT09PQ0KPiA+DQo+ID4gV2hl biBkb2luZyBhIEdFVCB3aXRoIGN1aWQ9LCBidXQgbm90IHRzaWQ9ICh0byBnZXQgdGhlIG1heC9t aW4gZXRjLg0KPiA+IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24pIHdoYXQgc2hvdWxkIGJlIHJl dHVybmVkIGluIHRoZSB0c2lkIGZpZWxkDQo+ID4gaW4gdGhlIHJlc3BvbnNlIGdpdmVuIHRoYXQg aXQgaXMgYSBrZXk/DQo+IA0KPiBbTWVkXSBHb29kIGNhdGNoLiBUaGlzIG9uZSBoYXMgdG8gYmUg Zml4ZWQuDQo+IA0KDQpbTWVkXSBUaGlzIGlzIHRoZSBuZXcgdHJlZSBzdHJ1Y3R1cmUgZm9yIHRl bGVtZXRyeS4gSWYgbm8gdHNpZCBpcyBwcmVzZW50LCBvbmx5ICJybyIgaXRlbXMgd2lsbCBiZSBy ZXR1cm5lZC4NCg0KDQogICAgKy0tOih0ZWxlbWV0cnktc2V0dXApIHtkb3RzLXRlbGVtZXRyeX0/ DQogICAgfCAgKy0tcm8gbWF4LWNvbmZpZy12YWx1ZXMNCiAgICB8ICB8ICArLS1ybyBtZWFzdXJl bWVudC1pbnRlcnZhbD8gICAgICAgICAgaW50ZXJ2YWwNCiAgICB8ICB8ICArLS1ybyBtZWFzdXJl bWVudC1zYW1wbGU/ICAgICAgICAgICAgc2FtcGxlDQogICAgfCAgfCAgKy0tcm8gbG93LXBlcmNl bnRpbGU/ICAgICAgICAgICAgICAgIHBlcmNlbnRpbGUNCiAgICB8ICB8ICArLS1ybyBtaWQtcGVy Y2VudGlsZT8gICAgICAgICAgICAgICAgcGVyY2VudGlsZQ0KICAgIHwgIHwgICstLXJvIGhpZ2gt cGVyY2VudGlsZT8gICAgICAgICAgICAgICBwZXJjZW50aWxlDQogICAgfCAgfCAgKy0tcm8gc2Vy dmVyLW9yaWdpbmF0ZWQtdGVsZW1ldHJ5PyAgIGJvb2xlYW4NCiAgICB8ICB8ICArLS1ybyB0ZWxl bWV0cnktbm90aWZ5LWludGVydmFsPyAgICAgdWludDMyDQogICAgfCAgKy0tcm8gbWluLWNvbmZp Zy12YWx1ZXMNCiAgICB8ICB8ICArLS1ybyBtZWFzdXJlbWVudC1pbnRlcnZhbD8gICAgICAgIGlu dGVydmFsDQogICAgfCAgfCAgKy0tcm8gbWVhc3VyZW1lbnQtc2FtcGxlPyAgICAgICAgICBzYW1w bGUNCiAgICB8ICB8ICArLS1ybyBsb3ctcGVyY2VudGlsZT8gICAgICAgICAgICAgIHBlcmNlbnRp bGUNCiAgICB8ICB8ICArLS1ybyBtaWQtcGVyY2VudGlsZT8gICAgICAgICAgICAgIHBlcmNlbnRp bGUNCiAgICB8ICB8ICArLS1ybyBoaWdoLXBlcmNlbnRpbGU/ICAgICAgICAgICAgIHBlcmNlbnRp bGUNCiAgICB8ICB8ICArLS1ybyB0ZWxlbWV0cnktbm90aWZ5LWludGVydmFsPyAgIHVpbnQzMg0K ICAgIHwgICstLXJvIHN1cHBvcnRlZC11bml0cw0KICAgIHwgIHwgICstLXJvIHVuaXQtY29uZmln KiBbdW5pdF0NCiAgICB8ICB8ICAgICArLS1ybyB1bml0ICAgICAgICAgICB1bml0LXR5cGUNCiAg ICB8ICB8ICAgICArLS1ybyB1bml0LXN0YXR1cz8gICBib29sZWFuDQogICAgfCAgKy0tcncgdGVs ZW1ldHJ5KiBbY3VpZCB0c2lkXQ0KICAgIHwgICAgICstLXJ3IGN1aWQgICAgICAgICAgICAgICAg ICAgICAgICAgc3RyaW5nDQogICAgfCAgICAgKy0tcncgY2RpZD8gICAgICAgICAgICAgICAgICAg ICAgICBzdHJpbmcNCiAgICB8ICAgICArLS1ydyB0c2lkICAgICAgICAgICAgICAgICAgICAgICAg IHVpbnQzMg0KICAgIHwgICAgICstLXJ3IChzZXR1cC10eXBlKT8NCiAgICB8ICAgICAgICArLS06 KHRlbGVtZXRyeS1jb25maWcpDQogICAgfCAgICAgICAgfCAgKy0tcncgY3VycmVudC1jb25maWcN CiAgICB8ICAgICAgICB8ICAgICArLS1ydyBtZWFzdXJlbWVudC1pbnRlcnZhbD8gICAgICAgICAg aW50ZXJ2YWwNCiAgICB8ICAgICAgICB8ICAgICArLS1ydyBtZWFzdXJlbWVudC1zYW1wbGU/ICAg ICAgICAgICAgc2FtcGxlDQogICAgfCAgICAgICAgfCAgICAgKy0tcncgbG93LXBlcmNlbnRpbGU/ ICAgICAgICAgICAgICAgIHBlcmNlbnRpbGUNCiAgICB8ICAgICAgICB8ICAgICArLS1ydyBtaWQt cGVyY2VudGlsZT8gICAgICAgICAgICAgICAgcGVyY2VudGlsZQ0KICAgIHwgICAgICAgIHwgICAg ICstLXJ3IGhpZ2gtcGVyY2VudGlsZT8gICAgICAgICAgICAgICBwZXJjZW50aWxlDQogICAgfCAg ICAgICAgfCAgICAgKy0tcncgdW5pdC1jb25maWcqIFt1bml0XQ0KICAgIHwgICAgICAgIHwgICAg IHwgICstLXJ3IHVuaXQgICAgICAgICAgIHVuaXQtdHlwZQ0KICAgIHwgICAgICAgIHwgICAgIHwg ICstLXJ3IHVuaXQtc3RhdHVzPyAgIGJvb2xlYW4NCiAgICB8ICAgICAgICB8ICAgICArLS1ydyBz ZXJ2ZXItb3JpZ2luYXRlZC10ZWxlbWV0cnk/ICAgYm9vbGVhbg0KICAgIHwgICAgICAgIHwgICAg ICstLXJ3IHRlbGVtZXRyeS1ub3RpZnktaW50ZXJ2YWw/ICAgICB1aW50MzINCiAgICB8ICAgICAg ICArLS06KHBpcGUpDQogICAgfCAgICAgICAgfCAgKy0tcncgdG90YWwtcGlwZS1jYXBhY2l0eSog W2xpbmstaWQgdW5pdF0NCiAgICB8ICAgICAgICB8ICAgICArLS1ydyBsaW5rLWlkICAgICBudDps aW5rLWlkDQogICAgfCAgICAgICAgfCAgICAgKy0tcncgY2FwYWNpdHkgICAgdWludDY0DQogICAg fCAgICAgICAgfCAgICAgKy0tcncgdW5pdCAgICAgICAgdW5pdA0KICAgIHwgICAgICAgICstLToo YmFzZWxpbmUpDQo= From nobody Fri Apr 3 12:54: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 397CF3A0872 for ; Fri, 3 Apr 2020 12:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vZ97Tb1jRtJW for ; Fri, 3 Apr 2020 12:54:22 -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 867C23A0849 for ; Fri, 3 Apr 2020 12:54:20 -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 1jKSON-0002Wc-30; Fri, 03 Apr 2020 20:54:15 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 3 Apr 2020 20:54:15 +0100 Message-ID: <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlspoSv8VA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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, 03 Apr 2020 19:54:25 -0000 Hi Med, This looks good - I will give it a go to check nothing else creeps out of the woodwork! Thanks for all your help here and clear thinking. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 03 April 2020 19:59 > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org > Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots- > telemetry-05.txt > > Jon, > > > > > > > > /tm-setup > > > ======== > > > > > > When doing a GET with cuid=, but not tsid= (to get the max/min etc. > > > configuration information) what should be returned in the tsid field > > > in the response given that it is a key? > > > > [Med] Good catch. This one has to be fixed. > > > > [Med] This is the new tree structure for telemetry. If no tsid is present, only "ro" > items will be returned. > > > +--:(telemetry-setup) {dots-telemetry}? > | +--ro max-config-values > | | +--ro measurement-interval? interval > | | +--ro measurement-sample? sample > | | +--ro low-percentile? percentile > | | +--ro mid-percentile? percentile > | | +--ro high-percentile? percentile > | | +--ro server-originated-telemetry? boolean > | | +--ro telemetry-notify-interval? uint32 > | +--ro min-config-values > | | +--ro measurement-interval? interval > | | +--ro measurement-sample? sample > | | +--ro low-percentile? percentile > | | +--ro mid-percentile? percentile > | | +--ro high-percentile? percentile > | | +--ro telemetry-notify-interval? uint32 > | +--ro supported-units > | | +--ro unit-config* [unit] > | | +--ro unit unit-type > | | +--ro unit-status? boolean > | +--rw telemetry* [cuid tsid] > | +--rw cuid string > | +--rw cdid? string > | +--rw tsid uint32 > | +--rw (setup-type)? > | +--:(telemetry-config) > | | +--rw current-config > | | +--rw measurement-interval? interval > | | +--rw measurement-sample? sample > | | +--rw low-percentile? percentile > | | +--rw mid-percentile? percentile > | | +--rw high-percentile? percentile > | | +--rw unit-config* [unit] > | | | +--rw unit unit-type > | | | +--rw unit-status? boolean > | | +--rw server-originated-telemetry? boolean > | | +--rw telemetry-notify-interval? uint32 > | +--:(pipe) > | | +--rw total-pipe-capacity* [link-id unit] > | | +--rw link-id nt:link-id > | | +--rw capacity uint64 > | | +--rw unit unit > | +--:(baseline) > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Apr 4 02:42: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 E63353A1751 for ; Sat, 4 Apr 2020 02:42:09 -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, 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 eo19kiZYj__p for ; Sat, 4 Apr 2020 02:42: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 7578A3A174F for ; Sat, 4 Apr 2020 02:42:08 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 48vWzf4XT8zBrbm; Sat, 4 Apr 2020 11:42:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585993326; bh=0quvXc/fEVQDhWPC9IJ72aPmDqBM45tDJRN33+PyAKM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hvhTO21u8bnzGvMWfSIuy/rX7+vhq8mWMGB26fN6jMt+yoeSDMCP9V6jOS0ByPx2D R2Ym4TLi9U6zn0vCJGetZ+KPLGTTlP2j6Pb6+peatIU/U3IbSifrnlRZC4Jtpb2/K0 iAqKmJS2O1fKd1oFV1Cm1YbY6TDIPITHZaYHUTL8oK/n4CZiW57xSPv5m1M7q6GVWX Rk+A0jt5rtqlYqGO0Tqk1Oasjgz46DZdlDb+KOK4pcCBGvsD1DGQnFcMOS2yX47CLK LbTM9TZ7Of5eHA+eS1zwndeUC3V7ZO+4maP2A3fLPNL3Mc+iQOGSvFU9Zd/vV618/y P4EVUs9Vd3Law== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 48vWzf3VGYz2xC0; Sat, 4 Apr 2020 11:42:06 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlspoSv8VCAAOeFQA== Date: Sat, 4 Apr 2020 09:42:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> In-Reply-To: <134101d609f1$a76b6550$f6422ff0$@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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: Sat, 04 Apr 2020 09:42:10 -0000 Hi Jon, Great. The full updated tree structure can be found at: https://github.com/boucadair/draft-dots-telemetry/blob/master/tree-04.txt=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: vendredi 3 avril 2020 21:54 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for draft- > ietf-dots-telemetry-05.txt >=20 > Hi Med, >=20 > This looks good - I will give it a go to check nothing else creeps out > of > the woodwork! >=20 > Thanks for all your help here and clear thinking. >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > > Sent: 03 April 2020 19:59 > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; > dots@ietf.org > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > draft-ietf-dots- > > telemetry-05.txt > > > > Jon, > > > > > > > > > > > > /tm-setup > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > When doing a GET with cuid=3D, but not tsid=3D (to get the max/min > etc. > > > > configuration information) what should be returned in the tsid > field > > > > in the response given that it is a key? > > > > > > [Med] Good catch. This one has to be fixed. > > > > > > > [Med] This is the new tree structure for telemetry. If no tsid is > present, > only "ro" > > items will be returned. > > > > > > +--:(telemetry-setup) {dots-telemetry}? > > | +--ro max-config-values > > | | +--ro measurement-interval? interval > > | | +--ro measurement-sample? sample > > | | +--ro low-percentile? percentile > > | | +--ro mid-percentile? percentile > > | | +--ro high-percentile? percentile > > | | +--ro server-originated-telemetry? boolean > > | | +--ro telemetry-notify-interval? uint32 > > | +--ro min-config-values > > | | +--ro measurement-interval? interval > > | | +--ro measurement-sample? sample > > | | +--ro low-percentile? percentile > > | | +--ro mid-percentile? percentile > > | | +--ro high-percentile? percentile > > | | +--ro telemetry-notify-interval? uint32 > > | +--ro supported-units > > | | +--ro unit-config* [unit] > > | | +--ro unit unit-type > > | | +--ro unit-status? boolean > > | +--rw telemetry* [cuid tsid] > > | +--rw cuid string > > | +--rw cdid? string > > | +--rw tsid uint32 > > | +--rw (setup-type)? > > | +--:(telemetry-config) > > | | +--rw current-config > > | | +--rw measurement-interval? interval > > | | +--rw measurement-sample? sample > > | | +--rw low-percentile? percentile > > | | +--rw mid-percentile? percentile > > | | +--rw high-percentile? percentile > > | | +--rw unit-config* [unit] > > | | | +--rw unit unit-type > > | | | +--rw unit-status? boolean > > | | +--rw server-originated-telemetry? boolean > > | | +--rw telemetry-notify-interval? uint32 > > | +--:(pipe) > > | | +--rw total-pipe-capacity* [link-id unit] > > | | +--rw link-id nt:link-id > > | | +--rw capacity uint64 > > | | +--rw unit unit > > | +--:(baseline) > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Apr 4 08:21:59 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 CB10D3A0E99 for ; Sat, 4 Apr 2020 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oCitPjrTRinw for ; Sat, 4 Apr 2020 08:21:54 -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 903EC3A0E98 for ; Sat, 4 Apr 2020 08:21:54 -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 1jKkcG-0003JH-OS; Sat, 04 Apr 2020 16:21:48 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Sat, 4 Apr 2020 16:21:48 +0100 Message-ID: <13d301d60a94$c238aca0$46aa05e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlsAZwdohkCvxUmEaZjGSIA Content-Language: en-gb Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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: Sat, 04 Apr 2020 15:21:57 -0000 Hi All, A suggested change to reduce the information sent back when asking for = all the tmids and tsids as the requesting client will have the same cuid and = I think the same cdid. [Saves 22 bytes + CBOR overhead and same for cdid each time] OLD: +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] +--rw cuid string +--rw cdid? string +--rw tmid uint32 NEW: +--:(telemetry) {dots-telemetry}? +--rw cuid string +--rw cdid? String +--rw pre-or-ongoing-mitigation* [tmid] +--rw tmid uint32 OLD: +--:(telemetry-setup) {dots-telemetry}? | +--ro max-config-values .. | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 NEW: +--:(telemetry-setup) {dots-telemetry}? | +--ro max-config-values .. | +--rw cuid string | +--rw cdid? string | +--rw telemetry* [tsid] | +--rw tsid uint32 The same is true for signal mids, but I guess that is too late now. = Sigh. +--:(mitigation-scope) | +--rw scope* [cuid mid] | +--rw cdid? string | +--rw cuid string | +--rw mid Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 04 April 2020 10:42 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots- > telemetry-05.txt >=20 > Hi Jon, >=20 > Great. The full updated tree structure can be found at: >=20 > = https://github.com/boucadair/draft-dots-telemetry/blob/master/tree-04.txt= >=20 > Cheers, > Med >=20 >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: vendredi 3 avril 2020 21:54 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for = draft- > > ietf-dots-telemetry-05.txt > > > > Hi Med, > > > > This looks good - I will give it a go to check nothing else creeps = out > > of > > the woodwork! > > > > Thanks for all your help here and clear thinking. > > > > Regards > > > > Jon > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > > Sent: 03 April 2020 19:59 > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; > > dots@ietf.org > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > draft-ietf-dots- > > > telemetry-05.txt > > > > > > Jon, > > > > > > > > > > > > > > > > /tm-setup > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > When doing a GET with cuid=3D, but not tsid=3D (to get the = max/min > > etc. > > > > > configuration information) what should be returned in the tsid > > field > > > > > in the response given that it is a key? > > > > > > > > [Med] Good catch. This one has to be fixed. > > > > > > > > > > [Med] This is the new tree structure for telemetry. If no tsid is > > present, > > only "ro" > > > items will be returned. > > > > > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > | +--ro max-config-values > > > | | +--ro measurement-interval? interval > > > | | +--ro measurement-sample? sample > > > | | +--ro low-percentile? percentile > > > | | +--ro mid-percentile? percentile > > > | | +--ro high-percentile? percentile > > > | | +--ro server-originated-telemetry? boolean > > > | | +--ro telemetry-notify-interval? uint32 > > > | +--ro min-config-values > > > | | +--ro measurement-interval? interval > > > | | +--ro measurement-sample? sample > > > | | +--ro low-percentile? percentile > > > | | +--ro mid-percentile? percentile > > > | | +--ro high-percentile? percentile > > > | | +--ro telemetry-notify-interval? uint32 > > > | +--ro supported-units > > > | | +--ro unit-config* [unit] > > > | | +--ro unit unit-type > > > | | +--ro unit-status? boolean > > > | +--rw telemetry* [cuid tsid] > > > | +--rw cuid string > > > | +--rw cdid? string > > > | +--rw tsid uint32 > > > | +--rw (setup-type)? > > > | +--:(telemetry-config) > > > | | +--rw current-config > > > | | +--rw measurement-interval? interval > > > | | +--rw measurement-sample? sample > > > | | +--rw low-percentile? percentile > > > | | +--rw mid-percentile? percentile > > > | | +--rw high-percentile? percentile > > > | | +--rw unit-config* [unit] > > > | | | +--rw unit unit-type > > > | | | +--rw unit-status? boolean > > > | | +--rw server-originated-telemetry? boolean > > > | | +--rw telemetry-notify-interval? uint32 > > > | +--:(pipe) > > > | | +--rw total-pipe-capacity* [link-id unit] > > > | | +--rw link-id nt:link-id > > > | | +--rw capacity uint64 > > > | | +--rw unit unit > > > | +--:(baseline) > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Apr 4 08:50: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 12A203A0F17 for ; Sat, 4 Apr 2020 08:50:13 -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, 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 cuPq6tNSUNfV for ; Sat, 4 Apr 2020 08:50:11 -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 104743A0F15 for ; Sat, 4 Apr 2020 08:50:10 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48vh8J1GZ1z1yJk; Sat, 4 Apr 2020 17:50:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586015408; bh=857sf2lwtqHrOG7cZd07HU+EOyMCzSjg/lyYI4OeMDs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=agV7ckXQNC1t0yxr2WyOV1pNJCjIidO2sBXBgNtFe7Ka98dqVFruxlibx14D3ejTy l0QwvbQZLwOH7bLj+rhSdNhnn3nola+E0gchisKQDIad6IhBKTTJtGJovvHVZHpqpN gt0xuaSjyKeD1mVxTldbVqL7f1ovkD7myG5f4t24mjfdDBuu3x0MMoQBJ0FnA4ZstY cg+v578BRxYNK+j0sjGTFzZA7k3tDrxMMbI7E0mGa9UQ6Q9GZML7v3UnLFJkUhZ4jC nW8PFDRjoXtwMIlhHaBSQkcXO53DLkA/bVMhYK990T9+N2bYMxRFwDbWKyoi8psi9V 3j0aZHyCAvySg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48vh8J0Qrfz8sYd; Sat, 4 Apr 2020 17:50:08 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlsAZwdohkCvxUmEaZjGSIAgAAKklA= Date: Sat, 4 Apr 2020 15:50:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148E392@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13d301d60a94$c238aca0$46aa05e0$@jpshallow.com> In-Reply-To: <13d301d60a94$c238aca0$46aa05e0$@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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: Sat, 04 Apr 2020 15:50:14 -0000 Hi Jon, cuid and cdid MUST NOT be returned in the message body. That's said, I'm OK with the proposes change.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: samedi 4 avril 2020 17:22 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for draft- > ietf-dots-telemetry-05.txt >=20 > Hi All, >=20 > A suggested change to reduce the information sent back when asking for > all > the tmids and tsids as the requesting client will have the same cuid > and I > think the same cdid. > [Saves 22 bytes + CBOR overhead and same for cdid each time] >=20 > OLD: > +--:(telemetry) {dots-telemetry}? > +--rw pre-or-ongoing-mitigation* [cuid tmid] > +--rw cuid string > +--rw cdid? string > +--rw tmid uint32 > NEW: > +--:(telemetry) {dots-telemetry}? > +--rw cuid string > +--rw cdid? String > +--rw pre-or-ongoing-mitigation* [tmid] > +--rw tmid uint32 >=20 > OLD: > +--:(telemetry-setup) {dots-telemetry}? > | +--ro max-config-values > .. > | +--rw telemetry* [cuid tsid] > | +--rw cuid string > | +--rw cdid? string > | +--rw tsid uint32 >=20 > NEW: > +--:(telemetry-setup) {dots-telemetry}? > | +--ro max-config-values > .. > | +--rw cuid string > | +--rw cdid? string > | +--rw telemetry* [tsid] > | +--rw tsid uint32 >=20 > The same is true for signal mids, but I guess that is too late now. > Sigh. >=20 > +--:(mitigation-scope) > | +--rw scope* [cuid mid] > | +--rw cdid? string > | +--rw cuid string > | +--rw mid >=20 > Regards >=20 > Jon > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > > Sent: 04 April 2020 10:42 > > To: Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > draft-ietf-dots- > > telemetry-05.txt > > > > Hi Jon, > > > > Great. The full updated tree structure can be found at: > > > > https://github.com/boucadair/draft-dots-telemetry/blob/master/tree- > 04.txt > > > > Cheers, > > Med > > > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: vendredi 3 avril 2020 21:54 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for > draft- > > > ietf-dots-telemetry-05.txt > > > > > > Hi Med, > > > > > > This looks good - I will give it a go to check nothing else creeps > out > > > of > > > the woodwork! > > > > > > Thanks for all your help here and clear thinking. > > > > > > Regards > > > > > > Jon > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > > Sent: 03 April 2020 19:59 > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; > > > dots@ietf.org > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > > draft-ietf-dots- > > > > telemetry-05.txt > > > > > > > > Jon, > > > > > > > > > > > > > > > > > > > > /tm-setup > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > When doing a GET with cuid=3D, but not tsid=3D (to get the > max/min > > > etc. > > > > > > configuration information) what should be returned in the > tsid > > > field > > > > > > in the response given that it is a key? > > > > > > > > > > [Med] Good catch. This one has to be fixed. > > > > > > > > > > > > > [Med] This is the new tree structure for telemetry. If no tsid > is > > > present, > > > only "ro" > > > > items will be returned. > > > > > > > > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > | +--ro max-config-values > > > > | | +--ro measurement-interval? interval > > > > | | +--ro measurement-sample? sample > > > > | | +--ro low-percentile? percentile > > > > | | +--ro mid-percentile? percentile > > > > | | +--ro high-percentile? percentile > > > > | | +--ro server-originated-telemetry? boolean > > > > | | +--ro telemetry-notify-interval? uint32 > > > > | +--ro min-config-values > > > > | | +--ro measurement-interval? interval > > > > | | +--ro measurement-sample? sample > > > > | | +--ro low-percentile? percentile > > > > | | +--ro mid-percentile? percentile > > > > | | +--ro high-percentile? percentile > > > > | | +--ro telemetry-notify-interval? uint32 > > > > | +--ro supported-units > > > > | | +--ro unit-config* [unit] > > > > | | +--ro unit unit-type > > > > | | +--ro unit-status? boolean > > > > | +--rw telemetry* [cuid tsid] > > > > | +--rw cuid string > > > > | +--rw cdid? string > > > > | +--rw tsid uint32 > > > > | +--rw (setup-type)? > > > > | +--:(telemetry-config) > > > > | | +--rw current-config > > > > | | +--rw measurement-interval? interval > > > > | | +--rw measurement-sample? sample > > > > | | +--rw low-percentile? > percentile > > > > | | +--rw mid-percentile? > percentile > > > > | | +--rw high-percentile? > percentile > > > > | | +--rw unit-config* [unit] > > > > | | | +--rw unit unit-type > > > > | | | +--rw unit-status? boolean > > > > | | +--rw server-originated-telemetry? boolean > > > > | | +--rw telemetry-notify-interval? uint32 > > > > | +--:(pipe) > > > > | | +--rw total-pipe-capacity* [link-id unit] > > > > | | +--rw link-id nt:link-id > > > > | | +--rw capacity uint64 > > > > | | +--rw unit unit > > > > | +--:(baseline) > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Apr 4 09:01:43 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 6CA6C3A0F50 for ; Sat, 4 Apr 2020 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rBzTXFFo4Pvn for ; Sat, 4 Apr 2020 09:01:38 -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 9E7623A0F4F for ; Sat, 4 Apr 2020 09:01:37 -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 1jKlEl-0003Lr-Ki; Sat, 04 Apr 2020 17:01:35 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13d301d60a94$c238aca0$46aa05e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E392@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148E392@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Sat, 4 Apr 2020 17:01:35 +0100 Message-ID: <13da01d60a9a$50e69b60$f2b3d220$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlsAZwdohkCvxUmEQGaYEntAkiHKHimRA7zMA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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: Sat, 04 Apr 2020 16:01:41 -0000 Hi Med, Yes, you are right - I had fallen into the trap of making sure that what = was in the tree that was non optional was returned - and had forgotten the statement that was in the signal draft. So, the change then becomes a cosmetic one. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 04 April 2020 16:50 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots- > telemetry-05.txt >=20 > Hi Jon, >=20 > cuid and cdid MUST NOT be returned in the message body. >=20 > That's said, I'm OK with the proposes change. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: samedi 4 avril 2020 17:22 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for = draft- > > ietf-dots-telemetry-05.txt > > > > Hi All, > > > > A suggested change to reduce the information sent back when asking = for > > all > > the tmids and tsids as the requesting client will have the same cuid > > and I > > think the same cdid. > > [Saves 22 bytes + CBOR overhead and same for cdid each time] > > > > OLD: > > +--:(telemetry) {dots-telemetry}? > > +--rw pre-or-ongoing-mitigation* [cuid tmid] > > +--rw cuid string > > +--rw cdid? string > > +--rw tmid uint32 > > NEW: > > +--:(telemetry) {dots-telemetry}? > > +--rw cuid string > > +--rw cdid? String > > +--rw pre-or-ongoing-mitigation* [tmid] > > +--rw tmid uint32 > > > > OLD: > > +--:(telemetry-setup) {dots-telemetry}? > > | +--ro max-config-values > > .. > > | +--rw telemetry* [cuid tsid] > > | +--rw cuid string > > | +--rw cdid? string > > | +--rw tsid uint32 > > > > NEW: > > +--:(telemetry-setup) {dots-telemetry}? > > | +--ro max-config-values > > .. > > | +--rw cuid string > > | +--rw cdid? string > > | +--rw telemetry* [tsid] > > | +--rw tsid uint32 > > > > The same is true for signal mids, but I guess that is too late now. > > Sigh. > > > > +--:(mitigation-scope) > > | +--rw scope* [cuid mid] > > | +--rw cdid? string > > | +--rw cuid string > > | +--rw mid > > > > Regards > > > > Jon > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > > Sent: 04 April 2020 10:42 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > draft-ietf-dots- > > > telemetry-05.txt > > > > > > Hi Jon, > > > > > > Great. The full updated tree structure can be found at: > > > > > > = https://github.com/boucadair/draft-dots-telemetry/blob/master/tree- > > 04.txt > > > > > > Cheers, > > > Med > > > > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: vendredi 3 avril 2020 21:54 > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for > > draft- > > > > ietf-dots-telemetry-05.txt > > > > > > > > Hi Med, > > > > > > > > This looks good - I will give it a go to check nothing else = creeps > > out > > > > of > > > > the woodwork! > > > > > > > > Thanks for all your help here and clear thinking. > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > > Sent: 03 April 2020 19:59 > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; > > > > dots@ietf.org > > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > > > draft-ietf-dots- > > > > > telemetry-05.txt > > > > > > > > > > Jon, > > > > > > > > > > > > > > > > > > > > > > > > /tm-setup > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > When doing a GET with cuid=3D, but not tsid=3D (to get the > > max/min > > > > etc. > > > > > > > configuration information) what should be returned in the > > tsid > > > > field > > > > > > > in the response given that it is a key? > > > > > > > > > > > > [Med] Good catch. This one has to be fixed. > > > > > > > > > > > > > > > > [Med] This is the new tree structure for telemetry. If no tsid > > is > > > > present, > > > > only "ro" > > > > > items will be returned. > > > > > > > > > > > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > > | +--ro max-config-values > > > > > | | +--ro measurement-interval? interval > > > > > | | +--ro measurement-sample? sample > > > > > | | +--ro low-percentile? percentile > > > > > | | +--ro mid-percentile? percentile > > > > > | | +--ro high-percentile? percentile > > > > > | | +--ro server-originated-telemetry? boolean > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > | +--ro min-config-values > > > > > | | +--ro measurement-interval? interval > > > > > | | +--ro measurement-sample? sample > > > > > | | +--ro low-percentile? percentile > > > > > | | +--ro mid-percentile? percentile > > > > > | | +--ro high-percentile? percentile > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > | +--ro supported-units > > > > > | | +--ro unit-config* [unit] > > > > > | | +--ro unit unit-type > > > > > | | +--ro unit-status? boolean > > > > > | +--rw telemetry* [cuid tsid] > > > > > | +--rw cuid string > > > > > | +--rw cdid? string > > > > > | +--rw tsid uint32 > > > > > | +--rw (setup-type)? > > > > > | +--:(telemetry-config) > > > > > | | +--rw current-config > > > > > | | +--rw measurement-interval? = interval > > > > > | | +--rw measurement-sample? sample > > > > > | | +--rw low-percentile? > > percentile > > > > > | | +--rw mid-percentile? > > percentile > > > > > | | +--rw high-percentile? > > percentile > > > > > | | +--rw unit-config* [unit] > > > > > | | | +--rw unit unit-type > > > > > | | | +--rw unit-status? boolean > > > > > | | +--rw server-originated-telemetry? = boolean > > > > > | | +--rw telemetry-notify-interval? uint32 > > > > > | +--:(pipe) > > > > > | | +--rw total-pipe-capacity* [link-id unit] > > > > > | | +--rw link-id nt:link-id > > > > > | | +--rw capacity uint64 > > > > > | | +--rw unit unit > > > > > | +--:(baseline) > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat Apr 4 09:06: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 8F1E63A0F70 for ; Sat, 4 Apr 2020 09:06:30 -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, 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 TkJtFF7ZBCun for ; Sat, 4 Apr 2020 09:06:28 -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 A0C6E3A0F6E for ; Sat, 4 Apr 2020 09:06:28 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 48vhW64mfQzBs0f; Sat, 4 Apr 2020 18:06:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586016386; bh=VF0ob0WaZ7Rqu+QJ7DaWFl69TJtAaUE4lkAUrVc1mI0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=wavcCdiEuoVoVG73EjgxYSkeR1zVybVgfw9rkFP34FdkMt5vBlzprvulR7VXhYZZG n89dv+Fx+eWU0QVRiqr73s2K4XOYZYrbuTaSHafosfwH5yVlUmO4uejuy+fjNTRPMW 6KPS8RWY3dinPfOQ2Cx8HVTItsc+qS4NpKC4DuliRdBh3yITGPx3SghbP/EPC5HeXk rL6KwFWUV19kGzYjsKZatClVElodvPUHsPSuQV/6fhLugdNYLmCAr/JxUOsmzx65RA VZdFK/QxDLF/Sma8gvaXpIjLCOTxdNNKkyryJptgFhWN8Bd82WPkOacexnwCC7Hci2 slQ3m4/pSVnsA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 48vhW643QHzCqkT; Sat, 4 Apr 2020 18:06:26 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlsAZwdohkCvxUmEQGaYEntAkiHKHimRA7zMIAAArXA Date: Sat, 4 Apr 2020 16:06:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148E3CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13d301d60a94$c238aca0$46aa05e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E392@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13da01d60a9a$50e69b60$f2b3d220$@jpshallow.com> In-Reply-To: <13da01d60a9a$50e69b60$f2b3d220$@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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: Sat, 04 Apr 2020 16:06:31 -0000 Re-,=20 I will add a note to the document.=20 FYI, the tree is updated on the github.=20 Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: samedi 4 avril 2020 18:02 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for draft- > ietf-dots-telemetry-05.txt >=20 > Hi Med, >=20 > Yes, you are right - I had fallen into the trap of making sure that > what was > in the tree that was non optional was returned - and had forgotten the > statement that was in the signal draft. >=20 > So, the change then becomes a cosmetic one. >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > > Sent: 04 April 2020 16:50 > > To: Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > draft-ietf-dots- > > telemetry-05.txt > > > > Hi Jon, > > > > cuid and cdid MUST NOT be returned in the message body. > > > > That's said, I'm OK with the proposes change. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: samedi 4 avril 2020 17:22 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for > draft- > > > ietf-dots-telemetry-05.txt > > > > > > Hi All, > > > > > > A suggested change to reduce the information sent back when asking > for > > > all > > > the tmids and tsids as the requesting client will have the same > cuid > > > and I > > > think the same cdid. > > > [Saves 22 bytes + CBOR overhead and same for cdid each time] > > > > > > OLD: > > > +--:(telemetry) {dots-telemetry}? > > > +--rw pre-or-ongoing-mitigation* [cuid tmid] > > > +--rw cuid string > > > +--rw cdid? string > > > +--rw tmid uint32 > > > NEW: > > > +--:(telemetry) {dots-telemetry}? > > > +--rw cuid string > > > +--rw cdid? String > > > +--rw pre-or-ongoing-mitigation* [tmid] > > > +--rw tmid uint32 > > > > > > OLD: > > > +--:(telemetry-setup) {dots-telemetry}? > > > | +--ro max-config-values > > > .. > > > | +--rw telemetry* [cuid tsid] > > > | +--rw cuid string > > > | +--rw cdid? string > > > | +--rw tsid uint32 > > > > > > NEW: > > > +--:(telemetry-setup) {dots-telemetry}? > > > | +--ro max-config-values > > > .. > > > | +--rw cuid string > > > | +--rw cdid? string > > > | +--rw telemetry* [tsid] > > > | +--rw tsid uint32 > > > > > > The same is true for signal mids, but I guess that is too late > now. > > > Sigh. > > > > > > +--:(mitigation-scope) > > > | +--rw scope* [cuid mid] > > > | +--rw cdid? string > > > | +--rw cuid string > > > | +--rw mid > > > > > > Regards > > > > > > Jon > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > > Sent: 04 April 2020 10:42 > > > > To: Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > > draft-ietf-dots- > > > > telemetry-05.txt > > > > > > > > Hi Jon, > > > > > > > > Great. The full updated tree structure can be found at: > > > > > > > > https://github.com/boucadair/draft-dots- > telemetry/blob/master/tree- > > > 04.txt > > > > > > > > Cheers, > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: vendredi 3 avril 2020 21:54 > > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for > > > draft- > > > > > ietf-dots-telemetry-05.txt > > > > > > > > > > Hi Med, > > > > > > > > > > This looks good - I will give it a go to check nothing else > creeps > > > out > > > > > of > > > > > the woodwork! > > > > > > > > > > Thanks for all your help here and clear thinking. > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 03 April 2020 19:59 > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname > nishizuka; > > > > > dots@ietf.org > > > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification > for > > > > > draft-ietf-dots- > > > > > > telemetry-05.txt > > > > > > > > > > > > Jon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > /tm-setup > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > When doing a GET with cuid=3D, but not tsid=3D (to get the > > > max/min > > > > > etc. > > > > > > > > configuration information) what should be returned in > the > > > tsid > > > > > field > > > > > > > > in the response given that it is a key? > > > > > > > > > > > > > > [Med] Good catch. This one has to be fixed. > > > > > > > > > > > > > > > > > > > [Med] This is the new tree structure for telemetry. If no > tsid > > > is > > > > > present, > > > > > only "ro" > > > > > > items will be returned. > > > > > > > > > > > > > > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > > > | +--ro max-config-values > > > > > > | | +--ro measurement-interval? interval > > > > > > | | +--ro measurement-sample? sample > > > > > > | | +--ro low-percentile? percentile > > > > > > | | +--ro mid-percentile? percentile > > > > > > | | +--ro high-percentile? percentile > > > > > > | | +--ro server-originated-telemetry? boolean > > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > > | +--ro min-config-values > > > > > > | | +--ro measurement-interval? interval > > > > > > | | +--ro measurement-sample? sample > > > > > > | | +--ro low-percentile? percentile > > > > > > | | +--ro mid-percentile? percentile > > > > > > | | +--ro high-percentile? percentile > > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > > | +--ro supported-units > > > > > > | | +--ro unit-config* [unit] > > > > > > | | +--ro unit unit-type > > > > > > | | +--ro unit-status? boolean > > > > > > | +--rw telemetry* [cuid tsid] > > > > > > | +--rw cuid string > > > > > > | +--rw cdid? string > > > > > > | +--rw tsid uint32 > > > > > > | +--rw (setup-type)? > > > > > > | +--:(telemetry-config) > > > > > > | | +--rw current-config > > > > > > | | +--rw measurement-interval? > interval > > > > > > | | +--rw measurement-sample? > sample > > > > > > | | +--rw low-percentile? > > > percentile > > > > > > | | +--rw mid-percentile? > > > percentile > > > > > > | | +--rw high-percentile? > > > percentile > > > > > > | | +--rw unit-config* [unit] > > > > > > | | | +--rw unit unit-type > > > > > > | | | +--rw unit-status? boolean > > > > > > | | +--rw server-originated-telemetry? > boolean > > > > > > | | +--rw telemetry-notify-interval? > uint32 > > > > > > | +--:(pipe) > > > > > > | | +--rw total-pipe-capacity* [link-id unit] > > > > > > | | +--rw link-id nt:link-id > > > > > > | | +--rw capacity uint64 > > > > > > | | +--rw unit unit > > > > > > | +--:(baseline) > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Sun Apr 5 00:58:09 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 B74733A1622 for ; Sun, 5 Apr 2020 00:58:07 -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, 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 vm4CYCXA2nk0 for ; Sun, 5 Apr 2020 00:58:06 -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 C50CF3A16A5 for ; Sun, 5 Apr 2020 00:57:55 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 48w5cx61sbz2xdk; Sun, 5 Apr 2020 09:57:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586073473; bh=cK3JVUbng8tz4egHTJrdYwCa4Bva6soiZHfWDKa0ABc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=h9ZgpQb57aMYoIf2HpWLhr9epJx5sJxhKm9mq9XWev592CzN9MoXdRO3yz3cUQOOw xUO1LIVs4U8p5uPmHg7lzHtRe+Kj0WLoFR09URQ83iZiVjkQLkDlszcGHpMms0NLtw QwAchIYC6oEwXd+Nn6uwHPdnI9ePQ40sQzN7ELnr+QQqVEhj/CxOjThlrmVfigYcKX /ATfrYHHzoiO4J2nt50vSrZTbkj47yGAHpPZjP/AJVP2rTyIwI/ZsC7RDMIfuipsE7 n5AgWcAFdtmF/GMU6M5uskzN2OuY//yFTIvl6TASALIJGyDFGNhxssIXZKxuYymtUM 5iaA2WXUF/zoA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 48w5cx4X4GzCqk2; Sun, 5 Apr 2020 09:57:53 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: draft-ietf-dots-telemetry: URI-Query Thread-Index: AdYLH+bTGsXh37cFREacMq5ObiPcQg== Date: Sun, 5 Apr 2020 07:57:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148E648@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-telemetry: URI-Query 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: Sun, 05 Apr 2020 07:58:08 -0000 SGkgSm9uLCANCg0KRm9yIC90bSwgYSBjbGllbnQgdGhhdCBpcyBpbnRlcmVzdGVkIHRvIHJlY2Vp dmUgbm90aWZpY2F0aW9ucyBmb3IgYSBwYXJ0aWN1bGFyIHRhcmdldCAoQCwgcG9ydCwgcHJvdG9j b2wsIGV0Yy4pIGNhbiBtYWludGFpbiBvbmx5IGEgdG1pZCB3aXRoIHRoYXQgdGFyZ2V0IHVzaW5n IGEgUFVUIHJlcXVlc3QuIFdoYXQgaXMgdGhlIGJlbmVmaXQgaWYgdGhlIGRvdHMgY2xpZW50IHNl bmRzIGEgUFVUIC90bSBmb3IgYW4gSVAgcHJlZml4LCBidXQgdGhlbiBzZW5kcyBhIEdFVCB0byB0 YXJnZXQgdGhlIG5vdGlmaWNhdGlvbnMgYm91bmQgdG8gYSBzcGVjaWZpYyBwcm90b2NvbD8NCg0K Q2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpv biBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCj4gRW52b3nDqcKg OiB2ZW5kcmVkaSAzIGF2cmlsIDIwMjAgMTY6MTcNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQg VEdJL09MTjsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSRTogW0RvdHNdIC9taXRpZ2F0ZSBS RTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC0NCj4gaWV0Zi1kb3RzLXRlbGVt ZXRyeS0wNS50eHQNCj4gDQo+IA0KPiBKb24+IFdoYXQgYWJvdXQgdGhlIHVzZSBvZiBVcmktUXVl cmllcyB0byBmaWx0ZXIgb24gd2hhdCBpcyByZXR1cm5lZA0KPiBmb3IgYSBHRVQ/DQo+ID4NCg0K From nobody Sun Apr 5 07:33:05 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 D0F683A0ACC for ; Sun, 5 Apr 2020 07:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9ccqfNdr20Nq for ; Sun, 5 Apr 2020 07:33: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 B91E33A0ACB for ; Sun, 5 Apr 2020 07:33: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 1jL6KW-0004Ep-VN; Sun, 05 Apr 2020 15:32:57 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Sun, 5 Apr 2020 15:32:55 +0100 Message-ID: <148e01d60b57$18a0f3f0$49e2dbd0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwK25rW36R5rWx96QHgnlpzaSOc6e2UTAA Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query 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: Sun, 05 Apr 2020 14:33:05 -0000 Hi Med, I initially thought of using Queries for the /mitigate case - as a DOTS = client my IP is getting hammered so I put in a PUT /mitigate with just a = target-prefix for my IP. Then I can focus in on detail by doing a GET = /mitigation with Queries to filter down the potential abundance of data = flowing back with the telemetry extensions. Likewise, if I did a PUT = /mitigate with both target-prefix and target-port but am also interested = with what is happening on other ports I could do a GET /mitigate with = Queries which supersede what the PUT /mitigate specified. Yes, this can all be done with a PUT /tm and a vanilla GET /tm - but = then I would need to be sending both a PUT and GET - increasing traffic = - if I wanted to look at different scenarios and then add in a DELETE to = the mix to keep down the number of tmids. A big burst of analysis could = consume many tmids, and then we need to consider what happens when there = is a wraparound of the tmid counter. Here, a simple PUT to initiate = telemetry recording followed by GETs with different Queries may give = flexibility needed. >From the DOTS server perspective, at the CoAP level, each different tmid = for a cuid is a different resource which is potentially observable (and = so needs to be unique). Rapidly changing resources adds in unnecessary = overhead. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 05 April 2020 08:58 > To: Jon Shallow; dots@ietf.org > Subject: [Dots] draft-ietf-dots-telemetry: URI-Query >=20 > Hi Jon, >=20 > For /tm, a client that is interested to receive notifications for a = particular target > (@, port, protocol, etc.) can maintain only a tmid with that target = using a PUT > request. What is the benefit if the dots client sends a PUT /tm for an = IP prefix, > but then sends a GET to target the notifications bound to a specific = protocol? >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=C3=A9 : vendredi 3 avril 2020 16:17 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > Objet : RE: [Dots] /mitigate RE: New Version Notification for draft- > > ietf-dots-telemetry-05.txt > > > > > > Jon> What about the use of Uri-Queries to filter on what is returned > > for a GET? > > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 6 02:35:37 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 669873A0CAE for ; Mon, 6 Apr 2020 02:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 NsMe7E0qhtya for ; Mon, 6 Apr 2020 02:35:33 -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 03B393A0C87 for ; Mon, 6 Apr 2020 02:35:31 -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 1jLOA9-00056k-3X for ietf-supjps-dots@ietf.org; Mon, 06 Apr 2020 10:35:25 +0100 From: "Jon Shallow" To: Date: Mon, 6 Apr 2020 10:35:23 +0100 Message-ID: <154301d60bf6$b21158f0$16340ad0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYL9q+Bp8yfeG8pQDShfjmRU2oGhA== Content-Language: en-gb Archived-At: Subject: [Dots] draft-ietf-dots-telemetry: Large responses 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, 06 Apr 2020 09:35:36 -0000 Hi All, With support for telemetry status updates, there is a good chance that a status response will not fit into a single IP packet. Do we need a new CoAP Option or response code? These status responses are sent back using CoAP NON-confirmable packets - in other words the DOTS client does not have to acknowledge receipt of the packet which works in an environment where there is heavy packet loss in the same direction as the status packet - the DOTS server is not waiting on acknowledgement of the previous status packet before sending out the next one (which too may get dropped). For the status data that is larger than an IP packet, this can currently be handled in 2 ways that I can think of 1- Let IP fragmentation be used by sending large data that is fragmented across several IP packets 2- Make use of the CoAP BLOCK2 option (RFC9759) which is already referred to in the signal draft to create CoAP fragmentation. The disadvantage of (1) is that the receiving CoAP library has to have a large enough receive data buffer size to handle both the encrypted and then plaintext data. The libcoap library I use has the default receive buffer sized for that of an IP packet that is not fragmented. This buffer can be made bigger, but how big? What if the DOTS client is a constrained device with RAM etc. limitations? There is also a challenge of managing missing IP fragmented packets which is primarily done by the network stack. The disadvantage of (2) is that BLOCK2 is a synchronous transmission where the DOTS client receives a block of data and then has to request the next block of data. With a lossy network, if the client does not see a block of data then this status data transmission will stall and not recover leaving the DOTS server with outstanding data that cannot be transmitted and hence the need for garbage collection of failed transmissions. Furthermore with (2), RFC9759 recommends use of CONfirmable responses to handle potential packet loss - which does not work with a flooded pipe DDoS situation. I agree that if all can fit into one packet then this is not an issue, but enforcing that is difficult unless there are data reduction policies in place (such as using Queries or the remainder of the data is not sent (parameter/values deleted) and a response (may need new code) that says status is too large to fit into a packet or has been truncated). Another possibility is to create a new CoAP option that is equivalent to BLOCK2 in format but does not need to work symmetrically. Here, the DOTS server sequentially sends all of the CoAP fragmented data without requiring the DOTS client to request the next block (just as fragmented IP packets would be sent). It would then be up to the DOTS client to do the CoAP plain text block fragmentation re-assembly (again a limitation requiring more RAM on the DOTS client and garbage collection if there are missing packets). Using this new option reduces the load on the DOTS server who could be serving many DOTS clients. Thoughts? Regards Jon From nobody Mon Apr 6 02:50:43 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 DE5843A0D02 for ; Mon, 6 Apr 2020 02:50:40 -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, 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 6ZyVd1ve4be3 for ; Mon, 6 Apr 2020 02:50:38 -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 1ED583A0D05 for ; Mon, 6 Apr 2020 02:50:38 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 48wm4Q23SNzCqtv; Mon, 6 Apr 2020 11:50:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586166630; bh=9WJB0MEKo5PrrzxPHkiiFNKZqxC5AZqghulgw+EW5FQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=xFVwJRLsT741Vl+6Ao+FJytgfqNQkoysJySez/z8NGpzKys2sIgzeWKU84QYhPpLK vwWPSH8maEQsdzjWP4g8qhXfbF08TNpBa1Gh9/r2x7r+1UzbVzCLut6IRCCPnsN4pA 4KqNdx95B8j8YtZvqF6AYcZLIULXpg3yZldhfajyCjit4RSrbXQkQB+0Pv66W6swh4 UBycTq0WUcK3Fx86JjPRLc4BlFg7zyJBV3JRX3zplJPiPoDWEb2jR78FULeBy3okxP yUg1xJmQafvPkhbSHuT+ER+lJZKRV2dpDBpVb6Yw3Bfagzm797FUnZOqi8qSAfLgQO WANqyNoOI+8lA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48wm4Q1HvVz8sYw; Mon, 6 Apr 2020 11:50:30 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-telemetry: URI-Query Thread-Index: AQIwK25rW36R5rWx96QHgnlpzaSOc6e2UTAAgAFGi8A= Date: Mon, 6 Apr 2020 09:50:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148EC0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <148e01d60b57$18a0f3f0$49e2dbd0$@jpshallow.com> In-Reply-To: <148e01d60b57$18a0f3f0$49e2dbd0$@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query 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, 06 Apr 2020 09:50:41 -0000 SGkgSm9uLA0KDQpXZSBkbyBhbHJlYWR5IHVzZSBVcmktUXVlcnkgb3B0aW9ucyB0byBmaWx0ZXIg dGhlIEdFVCBkYXRhIGZvciAvbWl0aWdhdGUuIFdlIGNhbiBlbmhhbmNlIHRoYXQgZmVhdHVyZSB0 byBmdXJ0aGVyIGZpbHRlciBvdXQgZGF0YSBmb3IgcmVhc29ucyB0aGF0IGFyZSBzcGVjaWZpYyB0 byBhIERPVFMgY2xpZW50IChlLmcuLCBmb2N1cyBvbiBhIHNwZWNpZmljIGFsaWFzKS4gV2UgbWln aHQgY29uc2lkZXIgcmVxdWVzdHMgc3VjaCBhcyB0aGlzIG9uZToNCg0KICAgICBIZWFkZXI6IEdF VCAoQ29kZT0wLjAxKQ0KICAgICBVcmktUGF0aDogIi53ZWxsLWtub3duIg0KICAgICBVcmktUGF0 aDogImRvdHMiDQogICAgIFVyaS1QYXRoOiAibWl0aWdhdGUiDQogICAgIFVyaS1QYXRoOiAiY3Vp ZD1kejZwSGphQURrYUZUYmpyMEpHQnB3Ig0KICAgICBVcmktUGF0aDogIm1pZD0xMjMzMiINCiAg ICAgVXJpLVF1ZXJ5OiAidGFyZ2V0LWFsaWFzPWh0dHBzMSINCiAgICAgT2JzZXJ2ZTogMA0KDQpO ZXZlcnRoZWxlc3MsIEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gc2VuZCBhIEdFVCB3 aXRoIHRhcmdldHMgdGhhdCBzdXBlcnNlZGUgdGhlIG9uZSBvZiBhIC9taWQuIA0KDQpJZiBhbiBh Z2VudCBpcyBpbnRlcmVzdGVkIHRvIHJlY2VpdmUgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMg Zm9yIHRhcmdldHMgbm90IGNvdmVyZWQgYnkgYSBtaXRpZ2F0aW9uLCB0aGlzIHNob3VsZCBiZSBk b25lIHdpdGggL3RtICh0aGF0IGNhbiBiZSBmaWx0ZXJlZCB1c2luZyB0aGUgVXJpLXF1ZXJpZXMg YXMgYW4gYXR0YWNrIHByb2dyZXNzZXMpLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0 ZkBqcHNoYWxsb3cuY29tXQ0KPiBFbnZvecOpwqA6IGRpbWFuY2hlIDUgYXZyaWwgMjAyMCAxNjoz Mw0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBkb3RzQGlldGYub3JnDQo+IE9i amV0wqA6IFJFOiBbRG90c10gZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeTogVVJJLVF1ZXJ5DQo+ IA0KPiBIaSBNZWQsDQo+IA0KPiBJIGluaXRpYWxseSB0aG91Z2h0IG9mIHVzaW5nIFF1ZXJpZXMg Zm9yIHRoZSAvbWl0aWdhdGUgY2FzZSAtIGFzIGENCj4gRE9UUyBjbGllbnQgbXkgSVAgaXMgZ2V0 dGluZyBoYW1tZXJlZCBzbyBJIHB1dCBpbiBhIFBVVCAvbWl0aWdhdGUgd2l0aA0KPiBqdXN0IGEg dGFyZ2V0LXByZWZpeCBmb3IgbXkgSVAuICBUaGVuIEkgY2FuIGZvY3VzIGluIG9uIGRldGFpbCBi eQ0KPiBkb2luZyBhIEdFVCAvbWl0aWdhdGlvbiB3aXRoIFF1ZXJpZXMgdG8gZmlsdGVyIGRvd24g dGhlIHBvdGVudGlhbA0KPiBhYnVuZGFuY2Ugb2YgZGF0YSBmbG93aW5nIGJhY2sgd2l0aCB0aGUg dGVsZW1ldHJ5IGV4dGVuc2lvbnMuDQo+IExpa2V3aXNlLCBpZiBJIGRpZCBhIFBVVCAvbWl0aWdh dGUgd2l0aCBib3RoIHRhcmdldC1wcmVmaXggYW5kIHRhcmdldC0NCj4gcG9ydCBidXQgYW0gYWxz byBpbnRlcmVzdGVkIHdpdGggd2hhdCBpcyBoYXBwZW5pbmcgb24gb3RoZXIgcG9ydHMgSQ0KPiBj b3VsZCBkbyBhIEdFVCAvbWl0aWdhdGUgd2l0aCBRdWVyaWVzIHdoaWNoIHN1cGVyc2VkZSB3aGF0 IHRoZSBQVVQNCj4gL21pdGlnYXRlIHNwZWNpZmllZC4NCj4gDQo+IFllcywgdGhpcyBjYW4gYWxs IGJlIGRvbmUgd2l0aCBhIFBVVCAvdG0gYW5kIGEgdmFuaWxsYSBHRVQgL3RtIC0gYnV0DQo+IHRo ZW4gSSB3b3VsZCBuZWVkIHRvIGJlIHNlbmRpbmcgYm90aCBhIFBVVCBhbmQgR0VUIC0gaW5jcmVh c2luZw0KPiB0cmFmZmljIC0gaWYgSSB3YW50ZWQgdG8gbG9vayBhdCBkaWZmZXJlbnQgc2NlbmFy aW9zIGFuZCB0aGVuIGFkZCBpbiBhDQo+IERFTEVURSB0byB0aGUgbWl4IHRvIGtlZXAgZG93biB0 aGUgbnVtYmVyIG9mIHRtaWRzLiAgQSBiaWcgYnVyc3Qgb2YNCj4gYW5hbHlzaXMgY291bGQgY29u c3VtZSBtYW55IHRtaWRzLCBhbmQgdGhlbiB3ZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQNCj4gaGFw cGVucyB3aGVuIHRoZXJlIGlzIGEgd3JhcGFyb3VuZCBvZiB0aGUgdG1pZCBjb3VudGVyLiAgSGVy ZSwgYQ0KPiBzaW1wbGUgUFVUIHRvIGluaXRpYXRlIHRlbGVtZXRyeSByZWNvcmRpbmcgZm9sbG93 ZWQgYnkgR0VUcyB3aXRoDQo+IGRpZmZlcmVudCBRdWVyaWVzIG1heSBnaXZlIGZsZXhpYmlsaXR5 IG5lZWRlZC4NCj4gDQo+IEZyb20gdGhlIERPVFMgc2VydmVyIHBlcnNwZWN0aXZlLCBhdCB0aGUg Q29BUCBsZXZlbCwgZWFjaCBkaWZmZXJlbnQNCj4gdG1pZCBmb3IgYSBjdWlkIGlzIGEgZGlmZmVy ZW50IHJlc291cmNlIHdoaWNoIGlzIHBvdGVudGlhbGx5DQo+IG9ic2VydmFibGUgKGFuZCBzbyBu ZWVkcyB0byBiZSB1bmlxdWUpLiAgUmFwaWRseSBjaGFuZ2luZyByZXNvdXJjZXMNCj4gYWRkcyBp biB1bm5lY2Vzc2FyeSBvdmVyaGVhZC4NCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IEpvbg0KPiANCj4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERvdHMgW21haWx0bzogZG90 cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbQ0KPiA+IFNlbnQ6IDA1IEFwcmlsIDIwMjAgMDg6NTgNCj4gPiBUbzogSm9uIFNoYWxs b3c7IGRvdHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbRG90c10gZHJhZnQtaWV0Zi1kb3RzLXRl bGVtZXRyeTogVVJJLVF1ZXJ5DQo+ID4NCj4gPiBIaSBKb24sDQo+ID4NCj4gPiBGb3IgL3RtLCBh IGNsaWVudCB0aGF0IGlzIGludGVyZXN0ZWQgdG8gcmVjZWl2ZSBub3RpZmljYXRpb25zIGZvciBh DQo+IHBhcnRpY3VsYXIgdGFyZ2V0DQo+ID4gKEAsIHBvcnQsIHByb3RvY29sLCBldGMuKSBjYW4g bWFpbnRhaW4gb25seSBhIHRtaWQgd2l0aCB0aGF0IHRhcmdldA0KPiB1c2luZyBhIFBVVA0KPiA+ IHJlcXVlc3QuIFdoYXQgaXMgdGhlIGJlbmVmaXQgaWYgdGhlIGRvdHMgY2xpZW50IHNlbmRzIGEg UFVUIC90bSBmb3INCj4gYW4gSVAgcHJlZml4LA0KPiA+IGJ1dCB0aGVuIHNlbmRzIGEgR0VUIHRv IHRhcmdldCB0aGUgbm90aWZpY2F0aW9ucyBib3VuZCB0byBhIHNwZWNpZmljDQo+IHByb3RvY29s Pw0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4gPiA+IERlIDogSm9uIFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tXQ0KPiA+ID4gRW52b3nDqSA6IHZlbmRyZWRpIDMgYXZyaWwgMjAyMCAxNjox Nw0KPiA+ID4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBkb3RzQGlldGYub3JnDQo+ ID4gPiBPYmpldCA6IFJFOiBbRG90c10gL21pdGlnYXRlIFJFOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+IGRyYWZ0LQ0KPiA+ID4gaWV0Zi1kb3RzLXRlbGVtZXRyeS0wNS50eHQNCj4g PiA+DQo+ID4gPg0KPiA+ID4gSm9uPiBXaGF0IGFib3V0IHRoZSB1c2Ugb2YgVXJpLVF1ZXJpZXMg dG8gZmlsdGVyIG9uIHdoYXQgaXMNCj4gcmV0dXJuZWQNCj4gPiA+IGZvciBhIEdFVD8NCj4gPiA+ ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== From nobody Mon Apr 6 03:02:03 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 C891C3A0D35 for ; Mon, 6 Apr 2020 03:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t0WRxMmSCh71 for ; Mon, 6 Apr 2020 03:01:59 -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 DF0FA3A0D33 for ; Mon, 6 Apr 2020 03:01:58 -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 1jLOZn-00058O-Ul; Mon, 06 Apr 2020 11:01:56 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13d301d60a94$c238aca0$46aa05e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E392@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13da01d60a9a$50e69b60$f2b3d220$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E3CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148E3CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 6 Apr 2020 11:01:53 +0100 Message-ID: <154501d60bfa$664648a0$32d2d9e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlsAZwdohkCvxUmEQGaYEntAkiHKHgCMOeUSwGkBDQ7pibvsxA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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: Mon, 06 Apr 2020 10:02:02 -0000 Hi Med, Thanks for posting the new tree. I have gone back to trying to implement it and realise it needs to be thought through further. My suggestion of moving cuid and cdid up a level looks to be incorrect. = The top level should be an array, of which cuid is a key as that is a representation of the database behind all this that holds all the information under the /tm-setup resource (same is true for /tm = resource). The second issue is that current-configuration, pipe and baseline are = not allowed to be specified at the same time (as I understand it to be able = to easily handle conflicts etc.). They all have tsid as a key, but the = tsid across all 3 components may not be the same and updating 1 component = with a new tsid does not invalidate either of the other 2 components - only the updated component is deleted and a new one created. =20 A way forward could be to no longer make telemetry an array, but make = each of the 3 components an array indexed by tsid. Then it is a lot easier programmatically to handle individual components being updated. = Otherwise I am finding that I am having to give each component their own telemetry = array element and then merging / demerging things as things get updated. However, it is not immediately obvious how best to make each of the 3 components an array indexed by tsid if this is a better way to go = forward. The response to a GET for a tsid returns any of the 3 components that = match the tsid - as before, so no different here other than they are not = returned under a single telemetry array entry. There is some ambiguity in the PUT /tm-setup - we have tsid: Telemetry Setup Identifier is an identifier for the DOTS telemetry setup configuration data represented as an integer. This identifier MUST be generated by DOTS clients. 'tsid' values MUST increase monotonically (when a new PUT is generated by a DOTS client to convey new configuration parameters for the telemetry). And o If the DOTS server finds the 'tsid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the updated configuration parameters, 2.04 (Changed) MUST be returned in the response. Where the latter assumes we can use the same tsid. Are we allowed to = use the same tsid to update a configuration component or MUST we use a new = tsid? Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 04 April 2020 17:06 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots- > telemetry-05.txt >=20 > Re-, >=20 > I will add a note to the document. >=20 > FYI, the tree is updated on the github. >=20 > Thank you. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: samedi 4 avril 2020 18:02 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for = draft- > > ietf-dots-telemetry-05.txt > > > > Hi Med, > > > > Yes, you are right - I had fallen into the trap of making sure that > > what was > > in the tree that was non optional was returned - and had forgotten = the > > statement that was in the signal draft. > > > > So, the change then becomes a cosmetic one. > > > > Regards > > > > Jon > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > > Sent: 04 April 2020 16:50 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > draft-ietf-dots- > > > telemetry-05.txt > > > > > > Hi Jon, > > > > > > cuid and cdid MUST NOT be returned in the message body. > > > > > > That's said, I'm OK with the proposes change. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: samedi 4 avril 2020 17:22 > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for > > draft- > > > > ietf-dots-telemetry-05.txt > > > > > > > > Hi All, > > > > > > > > A suggested change to reduce the information sent back when = asking > > for > > > > all > > > > the tmids and tsids as the requesting client will have the same > > cuid > > > > and I > > > > think the same cdid. > > > > [Saves 22 bytes + CBOR overhead and same for cdid each time] > > > > > > > > OLD: > > > > +--:(telemetry) {dots-telemetry}? > > > > +--rw pre-or-ongoing-mitigation* [cuid tmid] > > > > +--rw cuid string > > > > +--rw cdid? string > > > > +--rw tmid uint32 > > > > NEW: > > > > +--:(telemetry) {dots-telemetry}? > > > > +--rw cuid string > > > > +--rw cdid? String > > > > +--rw pre-or-ongoing-mitigation* [tmid] > > > > +--rw tmid uint32 > > > > > > > > OLD: > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > | +--ro max-config-values > > > > .. > > > > | +--rw telemetry* [cuid tsid] > > > > | +--rw cuid string > > > > | +--rw cdid? string > > > > | +--rw tsid uint32 > > > > > > > > NEW: > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > | +--ro max-config-values > > > > .. > > > > | +--rw cuid string > > > > | +--rw cdid? string > > > > | +--rw telemetry* [tsid] > > > > | +--rw tsid uint32 > > > > > > > > The same is true for signal mids, but I guess that is too late > > now. > > > > Sigh. > > > > > > > > +--:(mitigation-scope) > > > > | +--rw scope* [cuid mid] > > > > | +--rw cdid? string > > > > | +--rw cuid string > > > > | +--rw mid > > > > > > > > Regards > > > > > > > > Jon > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > > Sent: 04 April 2020 10:42 > > > > > To: Jon Shallow; dots@ietf.org > > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > > > draft-ietf-dots- > > > > > telemetry-05.txt > > > > > > > > > > Hi Jon, > > > > > > > > > > Great. The full updated tree structure can be found at: > > > > > > > > > > https://github.com/boucadair/draft-dots- > > telemetry/blob/master/tree- > > > > 04.txt > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=E9=A0: vendredi 3 avril 2020 21:54 > > > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification = for > > > > draft- > > > > > > ietf-dots-telemetry-05.txt > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > This looks good - I will give it a go to check nothing else > > creeps > > > > out > > > > > > of > > > > > > the woodwork! > > > > > > > > > > > > Thanks for all your help here and clear thinking. > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 03 April 2020 19:59 > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname > > nishizuka; > > > > > > dots@ietf.org > > > > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification > > for > > > > > > draft-ietf-dots- > > > > > > > telemetry-05.txt > > > > > > > > > > > > > > Jon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /tm-setup > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > When doing a GET with cuid=3D, but not tsid=3D (to get = the > > > > max/min > > > > > > etc. > > > > > > > > > configuration information) what should be returned in > > the > > > > tsid > > > > > > field > > > > > > > > > in the response given that it is a key? > > > > > > > > > > > > > > > > [Med] Good catch. This one has to be fixed. > > > > > > > > > > > > > > > > > > > > > > [Med] This is the new tree structure for telemetry. If no > > tsid > > > > is > > > > > > present, > > > > > > only "ro" > > > > > > > items will be returned. > > > > > > > > > > > > > > > > > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > > > > | +--ro max-config-values > > > > > > > | | +--ro measurement-interval? interval > > > > > > > | | +--ro measurement-sample? sample > > > > > > > | | +--ro low-percentile? percentile > > > > > > > | | +--ro mid-percentile? percentile > > > > > > > | | +--ro high-percentile? percentile > > > > > > > | | +--ro server-originated-telemetry? boolean > > > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > > > | +--ro min-config-values > > > > > > > | | +--ro measurement-interval? interval > > > > > > > | | +--ro measurement-sample? sample > > > > > > > | | +--ro low-percentile? percentile > > > > > > > | | +--ro mid-percentile? percentile > > > > > > > | | +--ro high-percentile? percentile > > > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > > > | +--ro supported-units > > > > > > > | | +--ro unit-config* [unit] > > > > > > > | | +--ro unit unit-type > > > > > > > | | +--ro unit-status? boolean > > > > > > > | +--rw telemetry* [cuid tsid] > > > > > > > | +--rw cuid string > > > > > > > | +--rw cdid? string > > > > > > > | +--rw tsid uint32 > > > > > > > | +--rw (setup-type)? > > > > > > > | +--:(telemetry-config) > > > > > > > | | +--rw current-config > > > > > > > | | +--rw measurement-interval? > > interval > > > > > > > | | +--rw measurement-sample? > > sample > > > > > > > | | +--rw low-percentile? > > > > percentile > > > > > > > | | +--rw mid-percentile? > > > > percentile > > > > > > > | | +--rw high-percentile? > > > > percentile > > > > > > > | | +--rw unit-config* [unit] > > > > > > > | | | +--rw unit unit-type > > > > > > > | | | +--rw unit-status? boolean > > > > > > > | | +--rw server-originated-telemetry? > > boolean > > > > > > > | | +--rw telemetry-notify-interval? > > uint32 > > > > > > > | +--:(pipe) > > > > > > > | | +--rw total-pipe-capacity* [link-id unit] > > > > > > > | | +--rw link-id nt:link-id > > > > > > > | | +--rw capacity uint64 > > > > > > > | | +--rw unit unit > > > > > > > | +--:(baseline) > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 6 03:33: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 4FD263A0DBD for ; Mon, 6 Apr 2020 03:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i8zEOHgHmxMf for ; Mon, 6 Apr 2020 03:33:20 -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 749233A0DBC for ; Mon, 6 Apr 2020 03:33:20 -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 1jLP4A-00059R-Cw; Mon, 06 Apr 2020 11:33:18 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <148e01d60b57$18a0f3f0$49e2dbd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148EC0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148EC0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 6 Apr 2020 11:33:16 +0100 Message-ID: <155001d60bfe$c849d950$58dd8bf0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwK25rW36R5rWx96QHgnlpzaSOcwLKQkAQAqm6y22njARAsA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query 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, 06 Apr 2020 10:33:23 -0000 Hi Med et all, See inline Jon> Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 06 April 2020 10:50 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query >=20 > Hi Jon, >=20 > We do already use Uri-Query options to filter the GET data for = /mitigate. We can > enhance that feature to further filter out data for reasons that are = specific to a > DOTS client (e.g., focus on a specific alias). We might consider = requests such as > this one: >=20 > Header: GET (Code=3D0.01) > Uri-Path: ".well-known" > Uri-Path: "dots" > Uri-Path: "mitigate" > Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" > Uri-Path: "mid=3D12332" > Uri-Query: "target-alias=3Dhttps1" > Observe: 0 Jon> This works for me. Additionally, multiple queries for filtering = are valid - e.g. ... Uri-Path: "mid=3D12332" Uri-Query: "target-alias=3Dhttps1" Uri-Query: "target-alias=3Dhttps2" Uri-Query: "target-port=3D443" Observe: 0 >=20 > Nevertheless, I don't think it makes sense to send a GET with targets = that > supersede the one of a /mid. Jon> I am inclined to agree with you >=20 > If an agent is interested to receive asynchronous notifications for = targets not > covered by a mitigation, this should be done with /tm (that can be = filtered using > the Uri-queries as an attack progresses). Jon> Yes, a PUT /tm with a target-prefix is all that is needed and then = GET /tm with Queries is all that is needed for a tmid=3D ~Jon >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=C3=A9 : dimanche 5 avril 2020 16:33 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > Objet : RE: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > Hi Med, > > > > I initially thought of using Queries for the /mitigate case - as a > > DOTS client my IP is getting hammered so I put in a PUT /mitigate = with > > just a target-prefix for my IP. Then I can focus in on detail by > > doing a GET /mitigation with Queries to filter down the potential > > abundance of data flowing back with the telemetry extensions. > > Likewise, if I did a PUT /mitigate with both target-prefix and = target- > > port but am also interested with what is happening on other ports I > > could do a GET /mitigate with Queries which supersede what the PUT > > /mitigate specified. > > > > Yes, this can all be done with a PUT /tm and a vanilla GET /tm - but > > then I would need to be sending both a PUT and GET - increasing > > traffic - if I wanted to look at different scenarios and then add in = a > > DELETE to the mix to keep down the number of tmids. A big burst of > > analysis could consume many tmids, and then we need to consider what > > happens when there is a wraparound of the tmid counter. Here, a > > simple PUT to initiate telemetry recording followed by GETs with > > different Queries may give flexibility needed. > > > > From the DOTS server perspective, at the CoAP level, each different > > tmid for a cuid is a different resource which is potentially > > observable (and so needs to be unique). Rapidly changing resources > > adds in unnecessary overhead. > > > > Regards > > > > Jon > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > > Sent: 05 April 2020 08:58 > > > To: Jon Shallow; dots@ietf.org > > > Subject: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > Hi Jon, > > > > > > For /tm, a client that is interested to receive notifications for = a > > particular target > > > (@, port, protocol, etc.) can maintain only a tmid with that = target > > using a PUT > > > request. What is the benefit if the dots client sends a PUT /tm = for > > an IP prefix, > > > but then sends a GET to target the notifications bound to a = specific > > protocol? > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=C3=A9 : vendredi 3 avril 2020 16:17 > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > Objet : RE: [Dots] /mitigate RE: New Version Notification for > > draft- > > > > ietf-dots-telemetry-05.txt > > > > > > > > > > > > Jon> What about the use of Uri-Queries to filter on what is > > returned > > > > for a GET? > > > > > > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 6 03:37:57 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 C20F43A0DC8 for ; Mon, 6 Apr 2020 03:37:54 -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, 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 vyWsTlrLBBJK for ; Mon, 6 Apr 2020 03:37:52 -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 234283A0DC9 for ; Mon, 6 Apr 2020 03:37:52 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 48wn724rWtzCrGF; Mon, 6 Apr 2020 12:37:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586169470; bh=kYybsNeyt06tmh9l7t09y85nWMFWnW6Yjw/g6zb7mc8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UlJRwI335QWyG33dpP5n17zYB0j96kiz4U74XDBZEkoGtWGm91cPzKJNpn3nDNex9 W08zbTxdWGCalr0qa7B1+kD49YTqDu9M277v/z0W1tXs4+MQD7lOKduktuBUBXxkio yBMPTZfpe+VGPMrakVou77l6/zVuR30bzEFzrGXszBRmg42pQecQcve8HCPo/pR0+j KwfYhtjHORiW+E1ib71z3GD1lKyJc/mu1J+75FRcuWb1omuXaRIfMWW+lUzAs9TYXM HGxOjK8IEE8iW+S4C62DVDS46uiVJeAnVlbTN/7CHQnqTRQIrUQWl+bXKv0/QTvOWu wyogWySiGK4fQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 48wn7243XtzyQn; Mon, 6 Apr 2020 12:37:50 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AQLCJCHKTZTXlMfJ6YJ1Xfm++CQTzAFdVHlsAZwdohkCvxUmEQGaYEntAkiHKHgCMOeUSwGkBDQ7pibvsxCAATzfEA== Date: Mon, 6 Apr 2020 10:37:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148ED30@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148DB3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303148E084@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <134101d609f1$a76b6550$f6422ff0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E296@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13d301d60a94$c238aca0$46aa05e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E392@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <13da01d60a9a$50e69b60$f2b3d220$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148E3CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <154501d60bfa$664648a0$32d2d9e0$@jpshallow.com> In-Reply-To: <154501d60bfa$664648a0$32d2d9e0$@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.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: Mon, 06 Apr 2020 10:37:55 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: lundi 6 avril 2020 12:02 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for draft- > ietf-dots-telemetry-05.txt >=20 > Hi Med, >=20 > Thanks for posting the new tree. >=20 > I have gone back to trying to implement it and realise it needs to be > thought through further. >=20 > My suggestion of moving cuid and cdid up a level looks to be > incorrect. The > top level should be an array, of which cuid is a key as that is a > representation of the database [Med] Hmm. I would agree with you if we are using YANG to model what happen= ed at the server side to manage its state, but we are not using YANG for th= at. We are using YANG to model requests. As such, your modification is corr= ect as a request includes one and only one cuid. I will add a note to the d= raft to remind this.=20 behind all this that holds all the > information under the /tm-setup resource (same is true for /tm > resource). [Med] Idem as above >=20 > The second issue is that current-configuration, pipe and baseline are > not > allowed to be specified at the same time (as I understand it to be > able to > easily handle conflicts etc.).=20 [Med] I confirm.=20 They all have tsid as a key, but the > tsid > across all 3 components may not be the same [Med] It is not the same. and updating 1 component > with a > new tsid does not invalidate either of the other 2 components - only > the > updated component is deleted and a new one created. [Med] I confirm.=20 >=20 > A way forward could be to no longer make telemetry an array, but make > each > of the 3 components an array indexed by tsid. [Med] That's would work for pipe and baseline, but not for the telemetry-co= nfig. Telemetry-config is not an array on its own.=20 Then it is a lot easier > programmatically to handle individual components being updated. > Otherwise I > am finding that I am having to give each component their own telemetry > array > element and then merging / demerging things as things get updated. >=20 > However, it is not immediately obvious how best to make each of the 3 > components an array indexed by tsid if this is a better way to go > forward. [Med] For this to work, I'm afraid that these have to be indexed using dist= inct keys.=20 >=20 > The response to a GET for a tsid returns any of the 3 components that > match > the tsid - as before, so no different here other than they are not > returned > under a single telemetry array entry. >=20 > There is some ambiguity in the PUT /tm-setup - we have >=20 > tsid: Telemetry Setup Identifier is an identifier for the DOTS > telemetry setup configuration data represented as an integer. > This identifier MUST be generated by DOTS clients. 'tsid' > values MUST increase monotonically (when a new PUT is > generated > by a DOTS client to convey new configuration parameters for > the > telemetry). >=20 > And >=20 > o If the DOTS server finds the 'tsid' parameter value conveyed in > the PUT request in its configuration data and if the DOTS server > has accepted the updated configuration parameters, 2.04 > (Changed) > MUST be returned in the response. >=20 > Where the latter assumes we can use the same tsid. Are we allowed to > use > the same tsid to update a configuration component or MUST we use a new > tsid? >=20 [Med] This is to cover retransmitted requests. > Regards >=20 > Jon >=20 >=20 >=20 > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > > Sent: 04 April 2020 17:06 > > To: Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > draft-ietf-dots- > > telemetry-05.txt > > > > Re-, > > > > I will add a note to the document. > > > > FYI, the tree is updated on the github. > > > > Thank you. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: samedi 4 avril 2020 18:02 > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for > draft- > > > ietf-dots-telemetry-05.txt > > > > > > Hi Med, > > > > > > Yes, you are right - I had fallen into the trap of making sure > that > > > what was > > > in the tree that was non optional was returned - and had forgotten > the > > > statement that was in the signal draft. > > > > > > So, the change then becomes a cosmetic one. > > > > > > Regards > > > > > > Jon > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > > Sent: 04 April 2020 16:50 > > > > To: Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification for > > > draft-ietf-dots- > > > > telemetry-05.txt > > > > > > > > Hi Jon, > > > > > > > > cuid and cdid MUST NOT be returned in the message body. > > > > > > > > That's said, I'm OK with the proposes change. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: samedi 4 avril 2020 17:22 > > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification for > > > draft- > > > > > ietf-dots-telemetry-05.txt > > > > > > > > > > Hi All, > > > > > > > > > > A suggested change to reduce the information sent back when > asking > > > for > > > > > all > > > > > the tmids and tsids as the requesting client will have the > same > > > cuid > > > > > and I > > > > > think the same cdid. > > > > > [Saves 22 bytes + CBOR overhead and same for cdid each time] > > > > > > > > > > OLD: > > > > > +--:(telemetry) {dots-telemetry}? > > > > > +--rw pre-or-ongoing-mitigation* [cuid tmid] > > > > > +--rw cuid string > > > > > +--rw cdid? string > > > > > +--rw tmid uint32 > > > > > NEW: > > > > > +--:(telemetry) {dots-telemetry}? > > > > > +--rw cuid string > > > > > +--rw cdid? String > > > > > +--rw pre-or-ongoing-mitigation* [tmid] > > > > > +--rw tmid uint32 > > > > > > > > > > OLD: > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > > | +--ro max-config-values > > > > > .. > > > > > | +--rw telemetry* [cuid tsid] > > > > > | +--rw cuid string > > > > > | +--rw cdid? string > > > > > | +--rw tsid uint32 > > > > > > > > > > NEW: > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > > | +--ro max-config-values > > > > > .. > > > > > | +--rw cuid string > > > > > | +--rw cdid? string > > > > > | +--rw telemetry* [tsid] > > > > > | +--rw tsid uint32 > > > > > > > > > > The same is true for signal mids, but I guess that is too late > > > now. > > > > > Sigh. > > > > > > > > > > +--:(mitigation-scope) > > > > > | +--rw scope* [cuid mid] > > > > > | +--rw cdid? string > > > > > | +--rw cuid string > > > > > | +--rw mid > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 04 April 2020 10:42 > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > Subject: Re: [Dots] /tm-setup RE: New Version Notification > for > > > > > draft-ietf-dots- > > > > > > telemetry-05.txt > > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > Great. The full updated tree structure can be found at: > > > > > > > > > > > > https://github.com/boucadair/draft-dots- > > > telemetry/blob/master/tree- > > > > > 04.txt > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Envoy=E9=A0: vendredi 3 avril 2020 21:54 > > > > > > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > > > > Objet=A0: RE: [Dots] /tm-setup RE: New Version Notification > for > > > > > draft- > > > > > > > ietf-dots-telemetry-05.txt > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > This looks good - I will give it a go to check nothing > else > > > creeps > > > > > out > > > > > > > of > > > > > > > the woodwork! > > > > > > > > > > > > > > Thanks for all your help here and clear thinking. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: 03 April 2020 19:59 > > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname > > > nishizuka; > > > > > > > dots@ietf.org > > > > > > > > Subject: Re: [Dots] /tm-setup RE: New Version > Notification > > > for > > > > > > > draft-ietf-dots- > > > > > > > > telemetry-05.txt > > > > > > > > > > > > > > > > Jon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /tm-setup > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > When doing a GET with cuid=3D, but not tsid=3D (to get > the > > > > > max/min > > > > > > > etc. > > > > > > > > > > configuration information) what should be returned > in > > > the > > > > > tsid > > > > > > > field > > > > > > > > > > in the response given that it is a key? > > > > > > > > > > > > > > > > > > [Med] Good catch. This one has to be fixed. > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is the new tree structure for telemetry. If > no > > > tsid > > > > > is > > > > > > > present, > > > > > > > only "ro" > > > > > > > > items will be returned. > > > > > > > > > > > > > > > > > > > > > > > > +--:(telemetry-setup) {dots-telemetry}? > > > > > > > > | +--ro max-config-values > > > > > > > > | | +--ro measurement-interval? interval > > > > > > > > | | +--ro measurement-sample? sample > > > > > > > > | | +--ro low-percentile? > percentile > > > > > > > > | | +--ro mid-percentile? > percentile > > > > > > > > | | +--ro high-percentile? > percentile > > > > > > > > | | +--ro server-originated-telemetry? boolean > > > > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > > > > | +--ro min-config-values > > > > > > > > | | +--ro measurement-interval? interval > > > > > > > > | | +--ro measurement-sample? sample > > > > > > > > | | +--ro low-percentile? percentile > > > > > > > > | | +--ro mid-percentile? percentile > > > > > > > > | | +--ro high-percentile? percentile > > > > > > > > | | +--ro telemetry-notify-interval? uint32 > > > > > > > > | +--ro supported-units > > > > > > > > | | +--ro unit-config* [unit] > > > > > > > > | | +--ro unit unit-type > > > > > > > > | | +--ro unit-status? boolean > > > > > > > > | +--rw telemetry* [cuid tsid] > > > > > > > > | +--rw cuid string > > > > > > > > | +--rw cdid? string > > > > > > > > | +--rw tsid uint32 > > > > > > > > | +--rw (setup-type)? > > > > > > > > | +--:(telemetry-config) > > > > > > > > | | +--rw current-config > > > > > > > > | | +--rw measurement-interval? > > > interval > > > > > > > > | | +--rw measurement-sample? > > > sample > > > > > > > > | | +--rw low-percentile? > > > > > percentile > > > > > > > > | | +--rw mid-percentile? > > > > > percentile > > > > > > > > | | +--rw high-percentile? > > > > > percentile > > > > > > > > | | +--rw unit-config* [unit] > > > > > > > > | | | +--rw unit unit-type > > > > > > > > | | | +--rw unit-status? boolean > > > > > > > > | | +--rw server-originated-telemetry? > > > boolean > > > > > > > > | | +--rw telemetry-notify-interval? > > > uint32 > > > > > > > > | +--:(pipe) > > > > > > > > | | +--rw total-pipe-capacity* [link-id > unit] > > > > > > > > | | +--rw link-id nt:link-id > > > > > > > > | | +--rw capacity uint64 > > > > > > > > | | +--rw unit unit > > > > > > > > | +--:(baseline) > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 6 03:40:20 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 B4FC63A0DE3 for ; Mon, 6 Apr 2020 03:40:18 -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, 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 Vh2EOwRKztFU for ; Mon, 6 Apr 2020 03:40:16 -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 288173A0DE0 for ; Mon, 6 Apr 2020 03:40:16 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48wn9p4YM1zFpjQ; Mon, 6 Apr 2020 12:40:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586169614; bh=JXFeKpnBgvO/gMRj7LZ1Iw2J4CB2DYxVLVTZr2xi5M8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=qkMpHUs0V1G6cnsnk7ZZ/n6aKl7iDtwgn2QXhrT/8m+OeG1x6K6hr/9PhbSSsbWOT wbhUFffreK7MpZvB3behNIYRzt/lRSnEEnU39jifm+TlJHJtzKMwx0k/I7QaTSPtL4 b6oyScI42KA1YwAid6HcuhVv6IWQcFqAtdcQQFMf0f2EQKnyYl4IfqXaiputtGttAS 9v5v44FCd/ZCrFQLECsb283lBdehDs6cBR9NdZy+5IZb2xkW+PQYKNbcIrkFuuDzJz UpfsgpTp+ZSu2SKj3pOueWJ/+jExkAtliVYNsVtMKqvHA2098JDgeh4FdE+hlSxjOe BLr1d5DSh9v9g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48wn9p3fJnzBrLR; Mon, 6 Apr 2020 12:40:14 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-telemetry: URI-Query Thread-Index: AQIwK25rW36R5rWx96QHgnlpzaSOcwLKQkAQAqm6y22njARAsIAABANg Date: Mon, 6 Apr 2020 10:40:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148ED44@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <148e01d60b57$18a0f3f0$49e2dbd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148EC0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <155001d60bfe$c849d950$58dd8bf0$@jpshallow.com> In-Reply-To: <155001d60bfe$c849d950$58dd8bf0$@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query 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, 06 Apr 2020 10:40:19 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWll dGZAanBzaGFsbG93LmNvbV0NCj4gRW52b3nDqcKgOiBsdW5kaSA2IGF2cmlsIDIwMjAgMTI6MzMN Cj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgZG90c0BpZXRmLm9yZw0KPiBPYmpl dMKgOiBSRTogW0RvdHNdIGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnk6IFVSSS1RdWVyeQ0KPiAN Cj4gSGkgTWVkIGV0IGFsbCwNCj4gDQo+IFNlZSBpbmxpbmUgSm9uPg0KPiANCj4gUmVnYXJkcw0K PiANCj4gSm9uDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog RG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gU2VudDogMDYgQXByaWwgMjAyMCAxMDo1MA0K PiA+IFRvOiBKb24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbRG90 c10gZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeTogVVJJLVF1ZXJ5DQo+ID4NCj4gPiBIaSBKb24s DQo+ID4NCj4gPiBXZSBkbyBhbHJlYWR5IHVzZSBVcmktUXVlcnkgb3B0aW9ucyB0byBmaWx0ZXIg dGhlIEdFVCBkYXRhIGZvcg0KPiAvbWl0aWdhdGUuIFdlIGNhbg0KPiA+IGVuaGFuY2UgdGhhdCBm ZWF0dXJlIHRvIGZ1cnRoZXIgZmlsdGVyIG91dCBkYXRhIGZvciByZWFzb25zIHRoYXQgYXJlDQo+ IHNwZWNpZmljIHRvIGENCj4gPiBET1RTIGNsaWVudCAoZS5nLiwgZm9jdXMgb24gYSBzcGVjaWZp YyBhbGlhcykuIFdlIG1pZ2h0IGNvbnNpZGVyDQo+IHJlcXVlc3RzIHN1Y2ggYXMNCj4gPiB0aGlz IG9uZToNCj4gPg0KPiA+ICAgICAgSGVhZGVyOiBHRVQgKENvZGU9MC4wMSkNCj4gPiAgICAgIFVy aS1QYXRoOiAiLndlbGwta25vd24iDQo+ID4gICAgICBVcmktUGF0aDogImRvdHMiDQo+ID4gICAg ICBVcmktUGF0aDogIm1pdGlnYXRlIg0KPiA+ICAgICAgVXJpLVBhdGg6ICJjdWlkPWR6NnBIamFB RGthRlRianIwSkdCcHciDQo+ID4gICAgICBVcmktUGF0aDogIm1pZD0xMjMzMiINCj4gPiAgICAg IFVyaS1RdWVyeTogInRhcmdldC1hbGlhcz1odHRwczEiDQo+ID4gICAgICBPYnNlcnZlOiAwDQo+ IA0KPiBKb24+IFRoaXMgd29ya3MgZm9yIG1lLiAgQWRkaXRpb25hbGx5LCBtdWx0aXBsZSBxdWVy aWVzIGZvciBmaWx0ZXJpbmcNCj4gYXJlIHZhbGlkIC0gZS5nLg0KPiANCj4gLi4uDQo+ICAgICAg VXJpLVBhdGg6ICJtaWQ9MTIzMzIiDQo+ICAgICBVcmktUXVlcnk6ICJ0YXJnZXQtYWxpYXM9aHR0 cHMxIg0KPiAgICAgVXJpLVF1ZXJ5OiAidGFyZ2V0LWFsaWFzPWh0dHBzMiINCj4gICAgIFVyaS1R dWVyeTogInRhcmdldC1wb3J0PTQ0MyINCj4gICAgIE9ic2VydmU6IDANCj4gDQoNCltNZWRdIEFn cmVlLiBUaGlzIGlzIHdoYXQgSSBoYXZlIGluIG15IGxvY2FsIGNvcHk6DQoNCiAgIERPVFMgY2xp ZW50cyBjYW4gZmlsdGVyIG91dCB0aGUgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMgZnJvbSB0 aGUNCiAgIERPVFMgc2VydmVyIGJ5IGluZGljYXRpbmcgb25lIG9yIG1vcmUgVXJpLVF1ZXJ5IG9w dGlvbnMgaW4gaXRzIEdFVA0KICAgcmVxdWVzdC4gIEEgVXJpLVF1ZXJ5IG9wdGlvbiBjYW4gaW5j bHVkZSB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6DQogICB0YXJnZXQtcHJlZml4LCBsb3dlci1w b3J0LCB1cHBlci1wb3J0LCB0YXJnZXQtcHJvdG9jb2wsIHRhcmdldC1mcWRuLA0KICAgdGFyZ2V0 LXVyaSwgYWxpYXMtbmFtZS4gIEFuIGV4YW1wbGUgb2YgcmVxdWVzdCB0byBzdWJzY3JpYmUgdG8N CiAgIGFzeW5jaHJvbm91cyBub3RpZmljYXRpb25zIGJvdW5kIHRvIHRoZSAiaHR0cDEiIGFsaWFz IGlzIHNob3duIGluDQogICBGaWd1cmUgNDAuDQoNCiAgIElmIHRoZSB0YXJnZXQgcXVlcnkgZG9l cyBub3QgbWF0Y2ggdGhlIHRhcmdldCBvZiB0aGUgZW5jbG9zZWQgJ21pZCcNCiAgIGFzIG1haW50 YWluZWQgYnkgdGhlIERPVFMgc2VydmVyLCB0aGUgbGF0dGVyIE1VU1QgcmVzcG9uZCB3aXRoIGEg NC4wNA0KICAgKE5vdCBGb3VuZCkgZXJyb3IgcmVzcG9uc2UgY29kZS4gIFRoZSBET1RTIHNlcnZl ciBNVVNUIE5PVCBhZGQgYSBuZXcNCiAgIG9ic2VydmUgZW50cnkgaWYgdGhpcyBxdWVyeSBvdmVy bGFwcyB3aXRoIGFuIGV4aXN0aW5nIG9uZS4NCg0KPiANCj4gPg0KPiA+IE5ldmVydGhlbGVzcywg SSBkb24ndCB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBzZW5kIGEgR0VUIHdpdGgNCj4gdGFyZ2V0 cyB0aGF0DQo+ID4gc3VwZXJzZWRlIHRoZSBvbmUgb2YgYSAvbWlkLg0KPiANCj4gSm9uPiBJIGFt IGluY2xpbmVkIHRvIGFncmVlIHdpdGggeW91DQpbTWVkXSBUaGFua3MuIA0KDQoNCj4gPg0KPiA+ IElmIGFuIGFnZW50IGlzIGludGVyZXN0ZWQgdG8gcmVjZWl2ZSBhc3luY2hyb25vdXMgbm90aWZp Y2F0aW9ucyBmb3INCj4gdGFyZ2V0cyBub3QNCj4gPiBjb3ZlcmVkIGJ5IGEgbWl0aWdhdGlvbiwg dGhpcyBzaG91bGQgYmUgZG9uZSB3aXRoIC90bSAodGhhdCBjYW4gYmUNCj4gZmlsdGVyZWQgdXNp bmcNCj4gPiB0aGUgVXJpLXF1ZXJpZXMgYXMgYW4gYXR0YWNrIHByb2dyZXNzZXMpLg0KPiANCj4g Sm9uPiBZZXMsIGEgUFVUIC90bSB3aXRoIGEgdGFyZ2V0LXByZWZpeCBpcyBhbGwgdGhhdCBpcyBu ZWVkZWQgYW5kDQo+IHRoZW4gR0VUIC90bSB3aXRoIFF1ZXJpZXMgaXMgYWxsIHRoYXQgaXMgbmVl ZGVkIGZvciBhIHRtaWQ9DQoNCltNZWRdIERlYWwuICANCg0KPiB+Sm9uDQo+ID4NCj4gPiBDaGVl cnMsDQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ ID4gRGUgOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQo+ ID4gPiBFbnZvecOpIDogZGltYW5jaGUgNSBhdnJpbCAyMDIwIDE2OjMzDQo+ID4gPiDDgCA6IEJP VUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IGRvdHNAaWV0Zi5vcmcNCj4gPiA+IE9iamV0IDogUkU6 IFtEb3RzXSBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5OiBVUkktUXVlcnkNCj4gPiA+DQo+ID4g PiBIaSBNZWQsDQo+ID4gPg0KPiA+ID4gSSBpbml0aWFsbHkgdGhvdWdodCBvZiB1c2luZyBRdWVy aWVzIGZvciB0aGUgL21pdGlnYXRlIGNhc2UgLSBhcyBhDQo+ID4gPiBET1RTIGNsaWVudCBteSBJ UCBpcyBnZXR0aW5nIGhhbW1lcmVkIHNvIEkgcHV0IGluIGEgUFVUIC9taXRpZ2F0ZQ0KPiB3aXRo DQo+ID4gPiBqdXN0IGEgdGFyZ2V0LXByZWZpeCBmb3IgbXkgSVAuICBUaGVuIEkgY2FuIGZvY3Vz IGluIG9uIGRldGFpbCBieQ0KPiA+ID4gZG9pbmcgYSBHRVQgL21pdGlnYXRpb24gd2l0aCBRdWVy aWVzIHRvIGZpbHRlciBkb3duIHRoZSBwb3RlbnRpYWwNCj4gPiA+IGFidW5kYW5jZSBvZiBkYXRh IGZsb3dpbmcgYmFjayB3aXRoIHRoZSB0ZWxlbWV0cnkgZXh0ZW5zaW9ucy4NCj4gPiA+IExpa2V3 aXNlLCBpZiBJIGRpZCBhIFBVVCAvbWl0aWdhdGUgd2l0aCBib3RoIHRhcmdldC1wcmVmaXggYW5k DQo+IHRhcmdldC0NCj4gPiA+IHBvcnQgYnV0IGFtIGFsc28gaW50ZXJlc3RlZCB3aXRoIHdoYXQg aXMgaGFwcGVuaW5nIG9uIG90aGVyIHBvcnRzDQo+IEkNCj4gPiA+IGNvdWxkIGRvIGEgR0VUIC9t aXRpZ2F0ZSB3aXRoIFF1ZXJpZXMgd2hpY2ggc3VwZXJzZWRlIHdoYXQgdGhlIFBVVA0KPiA+ID4g L21pdGlnYXRlIHNwZWNpZmllZC4NCj4gPiA+DQo+ID4gPiBZZXMsIHRoaXMgY2FuIGFsbCBiZSBk b25lIHdpdGggYSBQVVQgL3RtIGFuZCBhIHZhbmlsbGEgR0VUIC90bSAtDQo+IGJ1dA0KPiA+ID4g dGhlbiBJIHdvdWxkIG5lZWQgdG8gYmUgc2VuZGluZyBib3RoIGEgUFVUIGFuZCBHRVQgLSBpbmNy ZWFzaW5nDQo+ID4gPiB0cmFmZmljIC0gaWYgSSB3YW50ZWQgdG8gbG9vayBhdCBkaWZmZXJlbnQg c2NlbmFyaW9zIGFuZCB0aGVuIGFkZA0KPiBpbiBhDQo+ID4gPiBERUxFVEUgdG8gdGhlIG1peCB0 byBrZWVwIGRvd24gdGhlIG51bWJlciBvZiB0bWlkcy4gIEEgYmlnIGJ1cnN0DQo+IG9mDQo+ID4g PiBhbmFseXNpcyBjb3VsZCBjb25zdW1lIG1hbnkgdG1pZHMsIGFuZCB0aGVuIHdlIG5lZWQgdG8g Y29uc2lkZXINCj4gd2hhdA0KPiA+ID4gaGFwcGVucyB3aGVuIHRoZXJlIGlzIGEgd3JhcGFyb3Vu ZCBvZiB0aGUgdG1pZCBjb3VudGVyLiAgSGVyZSwgYQ0KPiA+ID4gc2ltcGxlIFBVVCB0byBpbml0 aWF0ZSB0ZWxlbWV0cnkgcmVjb3JkaW5nIGZvbGxvd2VkIGJ5IEdFVHMgd2l0aA0KPiA+ID4gZGlm ZmVyZW50IFF1ZXJpZXMgbWF5IGdpdmUgZmxleGliaWxpdHkgbmVlZGVkLg0KPiA+ID4NCj4gPiA+ IEZyb20gdGhlIERPVFMgc2VydmVyIHBlcnNwZWN0aXZlLCBhdCB0aGUgQ29BUCBsZXZlbCwgZWFj aA0KPiBkaWZmZXJlbnQNCj4gPiA+IHRtaWQgZm9yIGEgY3VpZCBpcyBhIGRpZmZlcmVudCByZXNv dXJjZSB3aGljaCBpcyBwb3RlbnRpYWxseQ0KPiA+ID4gb2JzZXJ2YWJsZSAoYW5kIHNvIG5lZWRz IHRvIGJlIHVuaXF1ZSkuICBSYXBpZGx5IGNoYW5naW5nDQo+IHJlc291cmNlcw0KPiA+ID4gYWRk cyBpbiB1bm5lY2Vzc2FyeSBvdmVyaGVhZC4NCj4gPiA+DQo+ID4gPiBSZWdhcmRzDQo+ID4gPg0K PiA+ID4gSm9uDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gPiBGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+ID4gPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gPiA+IFNlbnQ6IDA1 IEFwcmlsIDIwMjAgMDg6NTgNCj4gPiA+ID4gVG86IEpvbiBTaGFsbG93OyBkb3RzQGlldGYub3Jn DQo+ID4gPiA+IFN1YmplY3Q6IFtEb3RzXSBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5OiBVUkkt UXVlcnkNCj4gPiA+ID4NCj4gPiA+ID4gSGkgSm9uLA0KPiA+ID4gPg0KPiA+ID4gPiBGb3IgL3Rt LCBhIGNsaWVudCB0aGF0IGlzIGludGVyZXN0ZWQgdG8gcmVjZWl2ZSBub3RpZmljYXRpb25zDQo+ IGZvciBhDQo+ID4gPiBwYXJ0aWN1bGFyIHRhcmdldA0KPiA+ID4gPiAoQCwgcG9ydCwgcHJvdG9j b2wsIGV0Yy4pIGNhbiBtYWludGFpbiBvbmx5IGEgdG1pZCB3aXRoIHRoYXQNCj4gdGFyZ2V0DQo+ ID4gPiB1c2luZyBhIFBVVA0KPiA+ID4gPiByZXF1ZXN0LiBXaGF0IGlzIHRoZSBiZW5lZml0IGlm IHRoZSBkb3RzIGNsaWVudCBzZW5kcyBhIFBVVCAvdG0NCj4gZm9yDQo+ID4gPiBhbiBJUCBwcmVm aXgsDQo+ID4gPiA+IGJ1dCB0aGVuIHNlbmRzIGEgR0VUIHRvIHRhcmdldCB0aGUgbm90aWZpY2F0 aW9ucyBib3VuZCB0byBhDQo+IHNwZWNpZmljDQo+ID4gPiBwcm90b2NvbD8NCj4gPiA+ID4NCj4g PiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBNZWQNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4gPiBEZSA6IEpvbiBTaGFsbG93IFttYWlsdG86c3Vw anBzLWlldGZAanBzaGFsbG93LmNvbV0NCj4gPiA+ID4gPiBFbnZvecOpIDogdmVuZHJlZGkgMyBh dnJpbCAyMDIwIDE2OjE3DQo+ID4gPiA+ID4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xO OyBkb3RzQGlldGYub3JnDQo+ID4gPiA+ID4gT2JqZXQgOiBSRTogW0RvdHNdIC9taXRpZ2F0ZSBS RTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ID4gZHJhZnQtDQo+ID4gPiA+ID4g aWV0Zi1kb3RzLXRlbGVtZXRyeS0wNS50eHQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gSm9uPiBXaGF0IGFib3V0IHRoZSB1c2Ugb2YgVXJpLVF1ZXJpZXMgdG8gZmlsdGVyIG9uIHdo YXQgaXMNCj4gPiA+IHJldHVybmVkDQo+ID4gPiA+ID4gZm9yIGEgR0VUPw0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gRG90c0BpZXRmLm9y Zw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== From nobody Mon Apr 6 03:54:56 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 2D9263A0E40 for ; Mon, 6 Apr 2020 03:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xdEIedfmcRpj for ; Mon, 6 Apr 2020 03:54:45 -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 B25263A0E25 for ; Mon, 6 Apr 2020 03:54: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 1jLPOk-0005B0-R0; Mon, 06 Apr 2020 11:54:35 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <148e01d60b57$18a0f3f0$49e2dbd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148EC0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <155001d60bfe$c849d950$58dd8bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148ED44@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148ED44@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 6 Apr 2020 11:54:32 +0100 Message-ID: <155f01d60c01$c1188ac0$4349a040$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwK25rW36R5rWx96QHgnlpzaSOcwLKQkAQAqm6y20B9KY3lgJDL0Sip2pMrnA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query 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, 06 Apr 2020 10:54:54 -0000 Hi Med, Do we need to say that Queries can be applied to GET /tm and GET = /mitigate (signal extension)? - it may be that you already have this text in elsewhere. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 06 April 2020 11:40 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=C3=A9 : lundi 6 avril 2020 12:33 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > Objet : RE: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > Hi Med et all, > > > > See inline Jon> > > > > Regards > > > > Jon > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > > Sent: 06 April 2020 10:50 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > Hi Jon, > > > > > > We do already use Uri-Query options to filter the GET data for > > /mitigate. We can > > > enhance that feature to further filter out data for reasons that = are > > specific to a > > > DOTS client (e.g., focus on a specific alias). We might consider > > requests such as > > > this one: > > > > > > Header: GET (Code=3D0.01) > > > Uri-Path: ".well-known" > > > Uri-Path: "dots" > > > Uri-Path: "mitigate" > > > Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" > > > Uri-Path: "mid=3D12332" > > > Uri-Query: "target-alias=3Dhttps1" > > > Observe: 0 > > > > Jon> This works for me. Additionally, multiple queries for = filtering > > are valid - e.g. > > > > ... > > Uri-Path: "mid=3D12332" > > Uri-Query: "target-alias=3Dhttps1" > > Uri-Query: "target-alias=3Dhttps2" > > Uri-Query: "target-port=3D443" > > Observe: 0 > > >=20 > [Med] Agree. This is what I have in my local copy: >=20 > DOTS clients can filter out the asynchronous notifications from the > DOTS server by indicating one or more Uri-Query options in its GET > request. A Uri-Query option can include the following parameters: > target-prefix, lower-port, upper-port, target-protocol, = target-fqdn, > target-uri, alias-name. An example of request to subscribe to > asynchronous notifications bound to the "http1" alias is shown in > Figure 40. >=20 > If the target query does not match the target of the enclosed 'mid' > as maintained by the DOTS server, the latter MUST respond with a = 4.04 > (Not Found) error response code. The DOTS server MUST NOT add a = new > observe entry if this query overlaps with an existing one. >=20 > > > > > > > > Nevertheless, I don't think it makes sense to send a GET with > > targets that > > > supersede the one of a /mid. > > > > Jon> I am inclined to agree with you > [Med] Thanks. >=20 >=20 > > > > > > If an agent is interested to receive asynchronous notifications = for > > targets not > > > covered by a mitigation, this should be done with /tm (that can be > > filtered using > > > the Uri-queries as an attack progresses). > > > > Jon> Yes, a PUT /tm with a target-prefix is all that is needed and > > then GET /tm with Queries is all that is needed for a tmid=3D >=20 > [Med] Deal. >=20 > > ~Jon > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=C3=A9 : dimanche 5 avril 2020 16:33 > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > Objet : RE: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > > > Hi Med, > > > > > > > > I initially thought of using Queries for the /mitigate case - as = a > > > > DOTS client my IP is getting hammered so I put in a PUT = /mitigate > > with > > > > just a target-prefix for my IP. Then I can focus in on detail = by > > > > doing a GET /mitigation with Queries to filter down the = potential > > > > abundance of data flowing back with the telemetry extensions. > > > > Likewise, if I did a PUT /mitigate with both target-prefix and > > target- > > > > port but am also interested with what is happening on other = ports > > I > > > > could do a GET /mitigate with Queries which supersede what the = PUT > > > > /mitigate specified. > > > > > > > > Yes, this can all be done with a PUT /tm and a vanilla GET /tm - > > but > > > > then I would need to be sending both a PUT and GET - increasing > > > > traffic - if I wanted to look at different scenarios and then = add > > in a > > > > DELETE to the mix to keep down the number of tmids. A big burst > > of > > > > analysis could consume many tmids, and then we need to consider > > what > > > > happens when there is a wraparound of the tmid counter. Here, a > > > > simple PUT to initiate telemetry recording followed by GETs with > > > > different Queries may give flexibility needed. > > > > > > > > From the DOTS server perspective, at the CoAP level, each > > different > > > > tmid for a cuid is a different resource which is potentially > > > > observable (and so needs to be unique). Rapidly changing > > resources > > > > adds in unnecessary overhead. > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > > Sent: 05 April 2020 08:58 > > > > > To: Jon Shallow; dots@ietf.org > > > > > Subject: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > > > > > Hi Jon, > > > > > > > > > > For /tm, a client that is interested to receive notifications > > for a > > > > particular target > > > > > (@, port, protocol, etc.) can maintain only a tmid with that > > target > > > > using a PUT > > > > > request. What is the benefit if the dots client sends a PUT = /tm > > for > > > > an IP prefix, > > > > > but then sends a GET to target the notifications bound to a > > specific > > > > protocol? > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=C3=A9 : vendredi 3 avril 2020 16:17 > > > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > > > Objet : RE: [Dots] /mitigate RE: New Version Notification = for > > > > draft- > > > > > > ietf-dots-telemetry-05.txt > > > > > > > > > > > > > > > > > > Jon> What about the use of Uri-Queries to filter on what is > > > > returned > > > > > > for a GET? > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 6 03:58: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 70B6F3A0E3B for ; Mon, 6 Apr 2020 03:58:39 -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, 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 J2Ic-45Wo3uv for ; Mon, 6 Apr 2020 03:58:37 -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 253163A0E36 for ; Mon, 6 Apr 2020 03:58:37 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 48wnZz6JQ6zymL; Mon, 6 Apr 2020 12:58:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586170715; bh=JudaHB2itsmOeC4LI3+AyK9eK9+Q+uR3nqsi/i1AGQU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=vCbB2ktZ7o/fQ5Stu+qk4b0ShRqalPy89SCvUiLInIF49EGCOrRR83l0l9oSVkPvX Fa/kVyK73+TdUOfxbj3Eiust/M47HyCtffxHb0IwQLGRi7Xxfq2gNWc63ZW7RIR1Fd vPB36x9hQ2ynuueUbZEdac7pUcRN1ITgfaQMG6B7UB8qptgdpmaDvbWkKU+u2yr4f6 1qH62z75p86m/m+H3kSsJeKfBk1p8OO5A1UBDxi9bPZXcxiV8OHztCkCTYQt/pvUgf TWH6dnUj3YQ303wHBJYHsdnZo4ntz9om+Y6Xm+NwL3ONR1p4c+dDtlEY/kawP1Ju1q 7bclfcNCVhX1g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 48wnZz5ZNnzDq7Z; Mon, 6 Apr 2020 12:58:35 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-telemetry: URI-Query Thread-Index: AQIwK25rW36R5rWx96QHgnlpzaSOcwLKQkAQAqm6y20B9KY3lgJDL0Sip2pMrnCAAAHdoA== Date: Mon, 6 Apr 2020 10:58:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148EDD9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <148e01d60b57$18a0f3f0$49e2dbd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148EC0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <155001d60bfe$c849d950$58dd8bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148ED44@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <155f01d60c01$c1188ac0$4349a040$@jpshallow.com> In-Reply-To: <155f01d60c01$c1188ac0$4349a040$@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query 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, 06 Apr 2020 10:58:40 -0000 UmUtLA0KDQpZZXMsIHRoaXMgd2lsbCBiZSBtZW50aW9uZWQgaW4gU2VjdGlvbiA3LjMuDQoNCkNo ZWVycywNCk1lZCANCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogSm9u IFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KPiBFbnZvecOpwqA6 IGx1bmRpIDYgYXZyaWwgMjAyMCAxMjo1NQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kv T0xOOyBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBbRG90c10gZHJhZnQtaWV0Zi1kb3Rz LXRlbGVtZXRyeTogVVJJLVF1ZXJ5DQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBEbyB3ZSBuZWVkIHRv IHNheSB0aGF0IFF1ZXJpZXMgY2FuIGJlIGFwcGxpZWQgdG8gR0VUIC90bSBhbmQgR0VUDQo+IC9t aXRpZ2F0ZSAoc2lnbmFsIGV4dGVuc2lvbik/DQo+IC0gaXQgbWF5IGJlIHRoYXQgeW91IGFscmVh ZHkgaGF2ZSB0aGlzIHRleHQgaW4gZWxzZXdoZXJlLg0KPiANCj4gUmVnYXJkcw0KPiANCj4gSm9u DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogRG90cyBbbWFp bHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tDQo+ID4gU2VudDogMDYgQXByaWwgMjAyMCAxMTo0MA0KPiA+IFRvOiBK b24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbRG90c10gZHJhZnQt aWV0Zi1kb3RzLXRlbGVtZXRyeTogVVJJLVF1ZXJ5DQo+ID4NCj4gPiBSZS0sDQo+ID4NCj4gPiBQ bGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+ID4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiBEZSA6IEpvbiBTaGFsbG93IFttYWls dG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCj4gPiA+IEVudm95w6kgOiBsdW5kaSA2IGF2 cmlsIDIwMjAgMTI6MzMNCj4gPiA+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgZG90 c0BpZXRmLm9yZw0KPiA+ID4gT2JqZXQgOiBSRTogW0RvdHNdIGRyYWZ0LWlldGYtZG90cy10ZWxl bWV0cnk6IFVSSS1RdWVyeQ0KPiA+ID4NCj4gPiA+IEhpIE1lZCBldCBhbGwsDQo+ID4gPg0KPiA+ ID4gU2VlIGlubGluZSBKb24+DQo+ID4gPg0KPiA+ID4gUmVnYXJkcw0KPiA+ID4NCj4gPiA+IEpv bg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJv bTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+ ID4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4gPiBTZW50OiAwNiBBcHJpbCAy MDIwIDEwOjUwDQo+ID4gPiA+IFRvOiBKb24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZw0KPiA+ID4g PiBTdWJqZWN0OiBSZTogW0RvdHNdIGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnk6IFVSSS1RdWVy eQ0KPiA+ID4gPg0KPiA+ID4gPiBIaSBKb24sDQo+ID4gPiA+DQo+ID4gPiA+IFdlIGRvIGFscmVh ZHkgdXNlIFVyaS1RdWVyeSBvcHRpb25zIHRvIGZpbHRlciB0aGUgR0VUIGRhdGEgZm9yDQo+ID4g PiAvbWl0aWdhdGUuIFdlIGNhbg0KPiA+ID4gPiBlbmhhbmNlIHRoYXQgZmVhdHVyZSB0byBmdXJ0 aGVyIGZpbHRlciBvdXQgZGF0YSBmb3IgcmVhc29ucyB0aGF0DQo+IGFyZQ0KPiA+ID4gc3BlY2lm aWMgdG8gYQ0KPiA+ID4gPiBET1RTIGNsaWVudCAoZS5nLiwgZm9jdXMgb24gYSBzcGVjaWZpYyBh bGlhcykuIFdlIG1pZ2h0IGNvbnNpZGVyDQo+ID4gPiByZXF1ZXN0cyBzdWNoIGFzDQo+ID4gPiA+ IHRoaXMgb25lOg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgIEhlYWRlcjogR0VUIChDb2RlPTAuMDEp DQo+ID4gPiA+ICAgICAgVXJpLVBhdGg6ICIud2VsbC1rbm93biINCj4gPiA+ID4gICAgICBVcmkt UGF0aDogImRvdHMiDQo+ID4gPiA+ICAgICAgVXJpLVBhdGg6ICJtaXRpZ2F0ZSINCj4gPiA+ID4g ICAgICBVcmktUGF0aDogImN1aWQ9ZHo2cEhqYUFEa2FGVGJqcjBKR0JwdyINCj4gPiA+ID4gICAg ICBVcmktUGF0aDogIm1pZD0xMjMzMiINCj4gPiA+ID4gICAgICBVcmktUXVlcnk6ICJ0YXJnZXQt YWxpYXM9aHR0cHMxIg0KPiA+ID4gPiAgICAgIE9ic2VydmU6IDANCj4gPiA+DQo+ID4gPiBKb24+ IFRoaXMgd29ya3MgZm9yIG1lLiAgQWRkaXRpb25hbGx5LCBtdWx0aXBsZSBxdWVyaWVzIGZvcg0K PiBmaWx0ZXJpbmcNCj4gPiA+IGFyZSB2YWxpZCAtIGUuZy4NCj4gPiA+DQo+ID4gPiAuLi4NCj4g PiA+ICAgICAgVXJpLVBhdGg6ICJtaWQ9MTIzMzIiDQo+ID4gPiAgICAgVXJpLVF1ZXJ5OiAidGFy Z2V0LWFsaWFzPWh0dHBzMSINCj4gPiA+ICAgICBVcmktUXVlcnk6ICJ0YXJnZXQtYWxpYXM9aHR0 cHMyIg0KPiA+ID4gICAgIFVyaS1RdWVyeTogInRhcmdldC1wb3J0PTQ0MyINCj4gPiA+ICAgICBP YnNlcnZlOiAwDQo+ID4gPg0KPiA+DQo+ID4gW01lZF0gQWdyZWUuIFRoaXMgaXMgd2hhdCBJIGhh dmUgaW4gbXkgbG9jYWwgY29weToNCj4gPg0KPiA+ICAgIERPVFMgY2xpZW50cyBjYW4gZmlsdGVy IG91dCB0aGUgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMgZnJvbQ0KPiB0aGUNCj4gPiAgICBE T1RTIHNlcnZlciBieSBpbmRpY2F0aW5nIG9uZSBvciBtb3JlIFVyaS1RdWVyeSBvcHRpb25zIGlu IGl0cw0KPiBHRVQNCj4gPiAgICByZXF1ZXN0LiAgQSBVcmktUXVlcnkgb3B0aW9uIGNhbiBpbmNs dWRlIHRoZSBmb2xsb3dpbmcNCj4gcGFyYW1ldGVyczoNCj4gPiAgICB0YXJnZXQtcHJlZml4LCBs b3dlci1wb3J0LCB1cHBlci1wb3J0LCB0YXJnZXQtcHJvdG9jb2wsIHRhcmdldC0NCj4gZnFkbiwN Cj4gPiAgICB0YXJnZXQtdXJpLCBhbGlhcy1uYW1lLiAgQW4gZXhhbXBsZSBvZiByZXF1ZXN0IHRv IHN1YnNjcmliZSB0bw0KPiA+ICAgIGFzeW5jaHJvbm91cyBub3RpZmljYXRpb25zIGJvdW5kIHRv IHRoZSAiaHR0cDEiIGFsaWFzIGlzIHNob3duIGluDQo+ID4gICAgRmlndXJlIDQwLg0KPiA+DQo+ ID4gICAgSWYgdGhlIHRhcmdldCBxdWVyeSBkb2VzIG5vdCBtYXRjaCB0aGUgdGFyZ2V0IG9mIHRo ZSBlbmNsb3NlZA0KPiAnbWlkJw0KPiA+ICAgIGFzIG1haW50YWluZWQgYnkgdGhlIERPVFMgc2Vy dmVyLCB0aGUgbGF0dGVyIE1VU1QgcmVzcG9uZCB3aXRoIGENCj4gNC4wNA0KPiA+ICAgIChOb3Qg Rm91bmQpIGVycm9yIHJlc3BvbnNlIGNvZGUuICBUaGUgRE9UUyBzZXJ2ZXIgTVVTVCBOT1QgYWRk IGENCj4gbmV3DQo+ID4gICAgb2JzZXJ2ZSBlbnRyeSBpZiB0aGlzIHF1ZXJ5IG92ZXJsYXBzIHdp dGggYW4gZXhpc3Rpbmcgb25lLg0KPiA+DQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBOZXZlcnRo ZWxlc3MsIEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gc2VuZCBhIEdFVCB3aXRoDQo+ ID4gPiB0YXJnZXRzIHRoYXQNCj4gPiA+ID4gc3VwZXJzZWRlIHRoZSBvbmUgb2YgYSAvbWlkLg0K PiA+ID4NCj4gPiA+IEpvbj4gSSBhbSBpbmNsaW5lZCB0byBhZ3JlZSB3aXRoIHlvdQ0KPiA+IFtN ZWRdIFRoYW5rcy4NCj4gPg0KPiA+DQo+ID4gPiA+DQo+ID4gPiA+IElmIGFuIGFnZW50IGlzIGlu dGVyZXN0ZWQgdG8gcmVjZWl2ZSBhc3luY2hyb25vdXMgbm90aWZpY2F0aW9ucw0KPiBmb3INCj4g PiA+IHRhcmdldHMgbm90DQo+ID4gPiA+IGNvdmVyZWQgYnkgYSBtaXRpZ2F0aW9uLCB0aGlzIHNo b3VsZCBiZSBkb25lIHdpdGggL3RtICh0aGF0IGNhbg0KPiBiZQ0KPiA+ID4gZmlsdGVyZWQgdXNp bmcNCj4gPiA+ID4gdGhlIFVyaS1xdWVyaWVzIGFzIGFuIGF0dGFjayBwcm9ncmVzc2VzKS4NCj4g PiA+DQo+ID4gPiBKb24+IFllcywgYSBQVVQgL3RtIHdpdGggYSB0YXJnZXQtcHJlZml4IGlzIGFs bCB0aGF0IGlzIG5lZWRlZCBhbmQNCj4gPiA+IHRoZW4gR0VUIC90bSB3aXRoIFF1ZXJpZXMgaXMg YWxsIHRoYXQgaXMgbmVlZGVkIGZvciBhIHRtaWQ9DQo+ID4NCj4gPiBbTWVkXSBEZWFsLg0KPiA+ DQo+ID4gPiB+Sm9uDQo+ID4gPiA+DQo+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gTWVkDQo+ID4g PiA+DQo+ID4gPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+ID4gRGUg OiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQo+ID4gPiA+ ID4gRW52b3nDqSA6IGRpbWFuY2hlIDUgYXZyaWwgMjAyMCAxNjozMw0KPiA+ID4gPiA+IMOAIDog Qk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gPiA+IE9iamV0 IDogUkU6IFtEb3RzXSBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5OiBVUkktUXVlcnkNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IEhpIE1lZCwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgaW5pdGlhbGx5 IHRob3VnaHQgb2YgdXNpbmcgUXVlcmllcyBmb3IgdGhlIC9taXRpZ2F0ZSBjYXNlIC0NCj4gYXMg YQ0KPiA+ID4gPiA+IERPVFMgY2xpZW50IG15IElQIGlzIGdldHRpbmcgaGFtbWVyZWQgc28gSSBw dXQgaW4gYSBQVVQNCj4gL21pdGlnYXRlDQo+ID4gPiB3aXRoDQo+ID4gPiA+ID4ganVzdCBhIHRh cmdldC1wcmVmaXggZm9yIG15IElQLiAgVGhlbiBJIGNhbiBmb2N1cyBpbiBvbiBkZXRhaWwNCj4g YnkNCj4gPiA+ID4gPiBkb2luZyBhIEdFVCAvbWl0aWdhdGlvbiB3aXRoIFF1ZXJpZXMgdG8gZmls dGVyIGRvd24gdGhlDQo+IHBvdGVudGlhbA0KPiA+ID4gPiA+IGFidW5kYW5jZSBvZiBkYXRhIGZs b3dpbmcgYmFjayB3aXRoIHRoZSB0ZWxlbWV0cnkgZXh0ZW5zaW9ucy4NCj4gPiA+ID4gPiBMaWtl d2lzZSwgaWYgSSBkaWQgYSBQVVQgL21pdGlnYXRlIHdpdGggYm90aCB0YXJnZXQtcHJlZml4IGFu ZA0KPiA+ID4gdGFyZ2V0LQ0KPiA+ID4gPiA+IHBvcnQgYnV0IGFtIGFsc28gaW50ZXJlc3RlZCB3 aXRoIHdoYXQgaXMgaGFwcGVuaW5nIG9uIG90aGVyDQo+IHBvcnRzDQo+ID4gPiBJDQo+ID4gPiA+ ID4gY291bGQgZG8gYSBHRVQgL21pdGlnYXRlIHdpdGggUXVlcmllcyB3aGljaCBzdXBlcnNlZGUg d2hhdCB0aGUNCj4gUFVUDQo+ID4gPiA+ID4gL21pdGlnYXRlIHNwZWNpZmllZC4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFllcywgdGhpcyBjYW4gYWxsIGJlIGRvbmUgd2l0aCBhIFBVVCAvdG0gYW5k IGEgdmFuaWxsYSBHRVQgL3RtDQo+IC0NCj4gPiA+IGJ1dA0KPiA+ID4gPiA+IHRoZW4gSSB3b3Vs ZCBuZWVkIHRvIGJlIHNlbmRpbmcgYm90aCBhIFBVVCBhbmQgR0VUIC0NCj4gaW5jcmVhc2luZw0K PiA+ID4gPiA+IHRyYWZmaWMgLSBpZiBJIHdhbnRlZCB0byBsb29rIGF0IGRpZmZlcmVudCBzY2Vu YXJpb3MgYW5kIHRoZW4NCj4gYWRkDQo+ID4gPiBpbiBhDQo+ID4gPiA+ID4gREVMRVRFIHRvIHRo ZSBtaXggdG8ga2VlcCBkb3duIHRoZSBudW1iZXIgb2YgdG1pZHMuICBBIGJpZw0KPiBidXJzdA0K PiA+ID4gb2YNCj4gPiA+ID4gPiBhbmFseXNpcyBjb3VsZCBjb25zdW1lIG1hbnkgdG1pZHMsIGFu ZCB0aGVuIHdlIG5lZWQgdG8NCj4gY29uc2lkZXINCj4gPiA+IHdoYXQNCj4gPiA+ID4gPiBoYXBw ZW5zIHdoZW4gdGhlcmUgaXMgYSB3cmFwYXJvdW5kIG9mIHRoZSB0bWlkIGNvdW50ZXIuICBIZXJl LA0KPiBhDQo+ID4gPiA+ID4gc2ltcGxlIFBVVCB0byBpbml0aWF0ZSB0ZWxlbWV0cnkgcmVjb3Jk aW5nIGZvbGxvd2VkIGJ5IEdFVHMNCj4gd2l0aA0KPiA+ID4gPiA+IGRpZmZlcmVudCBRdWVyaWVz IG1heSBnaXZlIGZsZXhpYmlsaXR5IG5lZWRlZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEZyb20g dGhlIERPVFMgc2VydmVyIHBlcnNwZWN0aXZlLCBhdCB0aGUgQ29BUCBsZXZlbCwgZWFjaA0KPiA+ ID4gZGlmZmVyZW50DQo+ID4gPiA+ID4gdG1pZCBmb3IgYSBjdWlkIGlzIGEgZGlmZmVyZW50IHJl c291cmNlIHdoaWNoIGlzIHBvdGVudGlhbGx5DQo+ID4gPiA+ID4gb2JzZXJ2YWJsZSAoYW5kIHNv IG5lZWRzIHRvIGJlIHVuaXF1ZSkuICBSYXBpZGx5IGNoYW5naW5nDQo+ID4gPiByZXNvdXJjZXMN Cj4gPiA+ID4gPiBhZGRzIGluIHVubmVjZXNzYXJ5IG92ZXJoZWFkLg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gUmVnYXJkcw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSm9uDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiBGcm9tOiBEb3Rz IFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gPiA+ID4g bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4gPiA+ID4gU2VudDogMDUgQXByaWwg MjAyMCAwODo1OA0KPiA+ID4gPiA+ID4gVG86IEpvbiBTaGFsbG93OyBkb3RzQGlldGYub3JnDQo+ ID4gPiA+ID4gPiBTdWJqZWN0OiBbRG90c10gZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeTogVVJJ LVF1ZXJ5DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSGkgSm9uLA0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IEZvciAvdG0sIGEgY2xpZW50IHRoYXQgaXMgaW50ZXJlc3RlZCB0byByZWNlaXZl DQo+IG5vdGlmaWNhdGlvbnMNCj4gPiA+IGZvciBhDQo+ID4gPiA+ID4gcGFydGljdWxhciB0YXJn ZXQNCj4gPiA+ID4gPiA+IChALCBwb3J0LCBwcm90b2NvbCwgZXRjLikgY2FuIG1haW50YWluIG9u bHkgYSB0bWlkIHdpdGggdGhhdA0KPiA+ID4gdGFyZ2V0DQo+ID4gPiA+ID4gdXNpbmcgYSBQVVQN Cj4gPiA+ID4gPiA+IHJlcXVlc3QuIFdoYXQgaXMgdGhlIGJlbmVmaXQgaWYgdGhlIGRvdHMgY2xp ZW50IHNlbmRzIGEgUFVUDQo+IC90bQ0KPiA+ID4gZm9yDQo+ID4gPiA+ID4gYW4gSVAgcHJlZml4 LA0KPiA+ID4gPiA+ID4gYnV0IHRoZW4gc2VuZHMgYSBHRVQgdG8gdGFyZ2V0IHRoZSBub3RpZmlj YXRpb25zIGJvdW5kIHRvIGENCj4gPiA+IHNwZWNpZmljDQo+ID4gPiA+ID4gcHJvdG9jb2w/DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gTWVkDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4g PiA+ID4gRGUgOiBKb24gU2hhbGxvdyBbbWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21d DQo+ID4gPiA+ID4gPiA+IEVudm95w6kgOiB2ZW5kcmVkaSAzIGF2cmlsIDIwMjAgMTY6MTcNCj4g PiA+ID4gPiA+ID4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBkb3RzQGlldGYub3Jn DQo+ID4gPiA+ID4gPiA+IE9iamV0IDogUkU6IFtEb3RzXSAvbWl0aWdhdGUgUkU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbg0KPiBmb3INCj4gPiA+ID4gPiBkcmFmdC0NCj4gPiA+ID4gPiA+ID4g aWV0Zi1kb3RzLXRlbGVtZXRyeS0wNS50eHQNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+ID4gSm9uPiBXaGF0IGFib3V0IHRoZSB1c2Ugb2YgVXJpLVF1ZXJpZXMgdG8g ZmlsdGVyIG9uIHdoYXQNCj4gaXMNCj4gPiA+ID4gPiByZXR1cm5lZA0KPiA+ID4gPiA+ID4gPiBm b3IgYSBHRVQ/DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4g RG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ID4gPg0KPiA+ ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID4gPiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBEb3RzQGlldGYub3JnDQo+ID4gPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBEb3RzIG1haWxp bmcgbGlzdA0KPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RvdHMNCg0K From nobody Mon Apr 6 04:00: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 446433A0E57 for ; Mon, 6 Apr 2020 04:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jWcNGGDbvctK for ; Mon, 6 Apr 2020 04:00:09 -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 34C483A0E54 for ; Mon, 6 Apr 2020 04:00:08 -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 1jLPU7-0005BX-Eh; Mon, 06 Apr 2020 12:00:07 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303148E648@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <148e01d60b57$18a0f3f0$49e2dbd0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148EC0C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <155001d60bfe$c849d950$58dd8bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148ED44@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <155f01d60c01$c1188ac0$4349a040$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148EDD9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148EDD9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 6 Apr 2020 12:00:05 +0100 Message-ID: <156401d60c02$87599030$960cb090$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwK25rW36R5rWx96QHgnlpzaSOcwLKQkAQAqm6y20B9KY3lgJDL0SiAjK6qAoCEpJThadIJQQw Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query 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, 06 Apr 2020 11:00:14 -0000 Thanks Med, Then I am good with the Queries changes. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 06 April 2020 11:59 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query >=20 > Re-, >=20 > Yes, this will be mentioned in Section 7.3. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=C3=A9 : lundi 6 avril 2020 12:55 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > Objet : RE: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > Hi Med, > > > > Do we need to say that Queries can be applied to GET /tm and GET > > /mitigate (signal extension)? > > - it may be that you already have this text in elsewhere. > > > > Regards > > > > Jon > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > > Sent: 06 April 2020 11:40 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=C3=A9 : lundi 6 avril 2020 12:33 > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > Objet : RE: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > > > Hi Med et all, > > > > > > > > See inline Jon> > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > > Sent: 06 April 2020 10:50 > > > > > To: Jon Shallow; dots@ietf.org > > > > > Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > > > > > Hi Jon, > > > > > > > > > > We do already use Uri-Query options to filter the GET data for > > > > /mitigate. We can > > > > > enhance that feature to further filter out data for reasons = that > > are > > > > specific to a > > > > > DOTS client (e.g., focus on a specific alias). We might = consider > > > > requests such as > > > > > this one: > > > > > > > > > > Header: GET (Code=3D0.01) > > > > > Uri-Path: ".well-known" > > > > > Uri-Path: "dots" > > > > > Uri-Path: "mitigate" > > > > > Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" > > > > > Uri-Path: "mid=3D12332" > > > > > Uri-Query: "target-alias=3Dhttps1" > > > > > Observe: 0 > > > > > > > > Jon> This works for me. Additionally, multiple queries for > > filtering > > > > are valid - e.g. > > > > > > > > ... > > > > Uri-Path: "mid=3D12332" > > > > Uri-Query: "target-alias=3Dhttps1" > > > > Uri-Query: "target-alias=3Dhttps2" > > > > Uri-Query: "target-port=3D443" > > > > Observe: 0 > > > > > > > > > > [Med] Agree. This is what I have in my local copy: > > > > > > DOTS clients can filter out the asynchronous notifications from > > the > > > DOTS server by indicating one or more Uri-Query options in its > > GET > > > request. A Uri-Query option can include the following > > parameters: > > > target-prefix, lower-port, upper-port, target-protocol, target- > > fqdn, > > > target-uri, alias-name. An example of request to subscribe to > > > asynchronous notifications bound to the "http1" alias is shown = in > > > Figure 40. > > > > > > If the target query does not match the target of the enclosed > > 'mid' > > > as maintained by the DOTS server, the latter MUST respond with = a > > 4.04 > > > (Not Found) error response code. The DOTS server MUST NOT add = a > > new > > > observe entry if this query overlaps with an existing one. > > > > > > > > > > > > > > > > > Nevertheless, I don't think it makes sense to send a GET with > > > > targets that > > > > > supersede the one of a /mid. > > > > > > > > Jon> I am inclined to agree with you > > > [Med] Thanks. > > > > > > > > > > > > > > > > If an agent is interested to receive asynchronous = notifications > > for > > > > targets not > > > > > covered by a mitigation, this should be done with /tm (that = can > > be > > > > filtered using > > > > > the Uri-queries as an attack progresses). > > > > > > > > Jon> Yes, a PUT /tm with a target-prefix is all that is needed = and > > > > then GET /tm with Queries is all that is needed for a tmid=3D > > > > > > [Med] Deal. > > > > > > > ~Jon > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=C3=A9 : dimanche 5 avril 2020 16:33 > > > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > > > Objet : RE: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > I initially thought of using Queries for the /mitigate case = - > > as a > > > > > > DOTS client my IP is getting hammered so I put in a PUT > > /mitigate > > > > with > > > > > > just a target-prefix for my IP. Then I can focus in on = detail > > by > > > > > > doing a GET /mitigation with Queries to filter down the > > potential > > > > > > abundance of data flowing back with the telemetry = extensions. > > > > > > Likewise, if I did a PUT /mitigate with both target-prefix = and > > > > target- > > > > > > port but am also interested with what is happening on other > > ports > > > > I > > > > > > could do a GET /mitigate with Queries which supersede what = the > > PUT > > > > > > /mitigate specified. > > > > > > > > > > > > Yes, this can all be done with a PUT /tm and a vanilla GET = /tm > > - > > > > but > > > > > > then I would need to be sending both a PUT and GET - > > increasing > > > > > > traffic - if I wanted to look at different scenarios and = then > > add > > > > in a > > > > > > DELETE to the mix to keep down the number of tmids. A big > > burst > > > > of > > > > > > analysis could consume many tmids, and then we need to > > consider > > > > what > > > > > > happens when there is a wraparound of the tmid counter. = Here, > > a > > > > > > simple PUT to initiate telemetry recording followed by GETs > > with > > > > > > different Queries may give flexibility needed. > > > > > > > > > > > > From the DOTS server perspective, at the CoAP level, each > > > > different > > > > > > tmid for a cuid is a different resource which is potentially > > > > > > observable (and so needs to be unique). Rapidly changing > > > > resources > > > > > > adds in unnecessary overhead. > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 05 April 2020 08:58 > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > Subject: [Dots] draft-ietf-dots-telemetry: URI-Query > > > > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > > > For /tm, a client that is interested to receive > > notifications > > > > for a > > > > > > particular target > > > > > > > (@, port, protocol, etc.) can maintain only a tmid with = that > > > > target > > > > > > using a PUT > > > > > > > request. What is the benefit if the dots client sends a = PUT > > /tm > > > > for > > > > > > an IP prefix, > > > > > > > but then sends a GET to target the notifications bound to = a > > > > specific > > > > > > protocol? > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Envoy=C3=A9 : vendredi 3 avril 2020 16:17 > > > > > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org > > > > > > > > Objet : RE: [Dots] /mitigate RE: New Version = Notification > > for > > > > > > draft- > > > > > > > > ietf-dots-telemetry-05.txt > > > > > > > > > > > > > > > > > > > > > > > > Jon> What about the use of Uri-Queries to filter on what > > is > > > > > > returned > > > > > > > > for a GET? > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 6 06:30: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 75B7D3A05A0 for ; Mon, 6 Apr 2020 05:57:09 -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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WRabIn50J_gY for ; Mon, 6 Apr 2020 05:56:44 -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 638C83A0597 for ; Mon, 6 Apr 2020 05:56:40 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 48wrCB44nbz4wZY; Mon, 6 Apr 2020 14:56:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586177798; bh=m4iCRCmBY3Kfe+TaebO8RtUSo3HxtumXnhd2HlD/UKU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UXOVipEyFO6pZY5faNkbGPVNZkdDS9lJhh5k31Qd6LHzt49Q7PNv/8mX2Qihi7Qsz t8UB/WXc/PZi5HZ1y4ZH2H+xO1ACV4GNAoy+IdI8iJSpeyVo8fGdvHmA73CKCpzUlZ oOI5ewsok052idjSO3Rpqpc606tGDG4NbTNx/OWiqSuZ5MNhUIn12GQhKpwEa1Ga5V Xi6r0XFWHs38o+eAF7qRJy0MQ+MiOxCEh2S31rSSmbQvZo9xV94DxvuJMfdNkJHUAn 7pedyJhsLFr7bA7/XR8LPm+GTyLtMEjPKOqgEWhuv2HrHuqa7bBIUn8Hjg7QxFUqy6 MBBmlPApHrQbw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 48wrCB3DPHzDq7q; Mon, 6 Apr 2020 14:56:38 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] draft-ietf-dots-telemetry: Large responses Thread-Index: AdYL9q+Bp8yfeG8pQDShfjmRU2oGhAAEpjqQ Date: Mon, 6 Apr 2020 12:56:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148EF95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154301d60bf6$b21158f0$16340ad0$@jpshallow.com> In-Reply-To: <154301d60bf6$b21158f0$16340ad0$@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: Large responses 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, 06 Apr 2020 12:57:25 -0000 Jon, If we had https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08#secti= on-5.7, this would solve the issue. Nevertheless, this is not implemented/d= eployed.=20 Your proposed option mimics the UDP FRAG behavior.=20 Because re-assembly would fail if a fragment is missing, notification fragm= ents with the new options should be sent, e.g., three times.=20 Ideally, we need a solution that allows to make use of partial responses ev= en if other fragments are lost.=20 Before considering a new option, let's see if we can solve this at the DOTS= layer. For example, we do have the following to avoid fragmentation:=20 If the total request size exceeds the path MTU then the DOTS client MUST split the DOTS signal into separate messages; for example, the list of addresses in the 'target- prefix' parameter could be split into multiple lists and each list conveyed in a new PUT request.=20 Does your implementation allow to follow a similar approach when sending no= tifications? For example, a first notification can include attack-traffic m= etrics and others include attack-details?=20 Because all these notifications are bound to the same tmid, the DOTS client= will update its local records with the data received in multiple notificat= ions.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > Envoy=E9=A0: lundi 6 avril 2020 11:35 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] draft-ietf-dots-telemetry: Large responses >=20 > Hi All, >=20 > With support for telemetry status updates, there is a good chance that > a > status response will not fit into a single IP packet. >=20 > Do we need a new CoAP Option or response code? >=20 > These status responses are sent back using CoAP NON-confirmable > packets - in > other words the DOTS client does not have to acknowledge receipt of > the > packet which works in an environment where there is heavy packet loss > in the > same direction as the status packet - the DOTS server is not waiting > on > acknowledgement of the previous status packet before sending out the > next > one (which too may get dropped). >=20 > For the status data that is larger than an IP packet, this can > currently be > handled in 2 ways that I can think of > 1- Let IP fragmentation be used by sending large data that is > fragmented > across several IP packets > 2- Make use of the CoAP BLOCK2 option (RFC9759) which is already > referred to > in the signal draft to create CoAP fragmentation. >=20 > The disadvantage of (1) is that the receiving CoAP library has to have > a > large enough receive data buffer size to handle both the encrypted and > then > plaintext data. The libcoap library I use has the default receive > buffer > sized for that of an IP packet that is not fragmented. This buffer > can be > made bigger, but how big? > What if the DOTS client is a constrained device with RAM etc. > limitations? > There is also a challenge of managing missing IP fragmented packets > which is > primarily done by the network stack. >=20 > The disadvantage of (2) is that BLOCK2 is a synchronous transmission > where > the DOTS client receives a block of data and then has to request the > next > block of data. With a lossy network, if the client does not see a > block of > data then this status data transmission will stall and not recover > leaving > the DOTS server with outstanding data that cannot be transmitted and > hence > the need for garbage collection of failed transmissions. > Furthermore with (2), RFC9759 recommends use of CONfirmable responses > to > handle potential packet loss - which does not work with a flooded pipe > DDoS > situation. >=20 > I agree that if all can fit into one packet then this is not an issue, > but > enforcing that is difficult unless there are data reduction policies > in > place (such as using Queries or the remainder of the data is not sent > (parameter/values deleted) and a response (may need new code) that > says > status is too large to fit into a packet or has been truncated). >=20 > Another possibility is to create a new CoAP option that is equivalent > to > BLOCK2 in format but does not need to work symmetrically. Here, the > DOTS > server sequentially sends all of the CoAP fragmented data without > requiring > the DOTS client to request the next block (just as fragmented IP > packets > would be sent). It would then be up to the DOTS client to do the CoAP > plain > text block fragmentation re-assembly (again a limitation requiring > more RAM > on the DOTS client and garbage collection if there are missing > packets). > Using this new option reduces the load on the DOTS server who could be > serving many DOTS clients. >=20 > Thoughts? >=20 > Regards >=20 > Jon >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 6 07:40: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 DDF963A0829 for ; Mon, 6 Apr 2020 07:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Hj--ULhYaciD for ; Mon, 6 Apr 2020 07:39:51 -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 2C6313A082B for ; Mon, 6 Apr 2020 07:39:49 -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 1jLSuh-0005I3-Oq; Mon, 06 Apr 2020 15:39:47 +0100 From: "Jon Shallow" To: , References: <154301d60bf6$b21158f0$16340ad0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303148EF95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303148EF95@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 6 Apr 2020 15:39:45 +0100 Message-ID: <159701d60c21$3758d130$a60a7390$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKZ0FSStX0COctgcBOdfSbmXAkZjgI+Qx5jptKiKnA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: Large responses 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, 06 Apr 2020 14:39:54 -0000 Hi Med, See inline Jon> Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 06 April 2020 13:57 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] draft-ietf-dots-telemetry: Large responses >=20 > Jon, >=20 > If we had https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08#section- > 5.7, this would solve the issue. Nevertheless, this is not implemented/deployed. > Your proposed option mimics the UDP FRAG behavior. >=20 > Because re-assembly would fail if a fragment is missing, notification fragments > with the new options should be sent, e.g., three times. Jon> This brings to mind the TCP SACK RFC2018 model which could be implemented at the DOTS layer, CBOR or CoAP layer (with new CoAP = option). See below. >=20 > Ideally, we need a solution that allows to make use of partial = responses even if > other fragments are lost. Jon> This would be nice. >=20 > Before considering a new option, let's see if we can solve this at the DOTS layer. > For example, we do have the following to avoid fragmentation: >=20 > If the total request size exceeds > the path MTU then the DOTS client MUST split the DOTS signal into > separate messages; for example, the list of addresses in the = 'target- > prefix' parameter could be split into multiple lists and each list > conveyed in a new PUT request. >=20 > Does your implementation allow to follow a similar approach when = sending > notifications? For example, a first notification can include attack-traffic metrics > and others include attack-details? Jon> Hmm, a GET only expects one (potentially re-assembled) response and then unsolicited observe responses with the same Token if observing. Additional responses could be sent as "Pseudo Observe" responses with = the same Token, but that assumes that the client is expecting Observe = responses - I think that would work in libcoap and the DOTS layer then taught what = to do. Jon> There still is a challenge of deciding what to send in each = individual pseudo response such that it is not larger than a packet (i.e. how best = to break down the status tree into component parts that are of the correct = size with CBOR varying length parameter values). There needs to be some knowledge of the DTLS + cipher overheads (and padding) to determine what = can fit in the IP MTU. With DTLS, we cannot use DTLS fragmentation as that = is for Handshake records only. Jon> I have only got so far as logging responses in the client, but = doing nothing with the data, so this is early days for me. >=20 > Because all these notifications are bound to the same tmid, the DOTS client will > update its local records with the data received in multiple = notifications. Jon> I think that this may work, but still am worried about getting data subsets into a packet and erring on the smaller side giving rise to more traffic (IP+UDP+DTLS overheads) than necessary which could compound the lossy issue. Jon> We also could handle the fragmentation at the CBOR level - a new parameter of "block" with block-no at the start of a new chunk record, = along with a "max-block" parameter (or perhaps "block" block-no is made up of maxblock and current block) and have a GET Query of block=3DX-Y,Z = (missing range and/or individual blocks, comma separated) to get the missing = ones. ~Jon >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > Envoy=E9=A0: lundi 6 avril 2020 11:35 > > =C0=A0: dots@ietf.org > > Objet=A0: [Dots] draft-ietf-dots-telemetry: Large responses > > > > Hi All, > > > > With support for telemetry status updates, there is a good chance = that > > a > > status response will not fit into a single IP packet. > > > > Do we need a new CoAP Option or response code? > > > > These status responses are sent back using CoAP NON-confirmable > > packets - in > > other words the DOTS client does not have to acknowledge receipt of > > the > > packet which works in an environment where there is heavy packet = loss > > in the > > same direction as the status packet - the DOTS server is not waiting > > on > > acknowledgement of the previous status packet before sending out the > > next > > one (which too may get dropped). > > > > For the status data that is larger than an IP packet, this can > > currently be > > handled in 2 ways that I can think of > > 1- Let IP fragmentation be used by sending large data that is > > fragmented > > across several IP packets > > 2- Make use of the CoAP BLOCK2 option (RFC9759) which is already > > referred to > > in the signal draft to create CoAP fragmentation. > > > > The disadvantage of (1) is that the receiving CoAP library has to = have > > a > > large enough receive data buffer size to handle both the encrypted = and > > then > > plaintext data. The libcoap library I use has the default receive > > buffer > > sized for that of an IP packet that is not fragmented. This buffer > > can be > > made bigger, but how big? > > What if the DOTS client is a constrained device with RAM etc. > > limitations? > > There is also a challenge of managing missing IP fragmented packets > > which is > > primarily done by the network stack. > > > > The disadvantage of (2) is that BLOCK2 is a synchronous transmission > > where > > the DOTS client receives a block of data and then has to request the > > next > > block of data. With a lossy network, if the client does not see a > > block of > > data then this status data transmission will stall and not recover > > leaving > > the DOTS server with outstanding data that cannot be transmitted and > > hence > > the need for garbage collection of failed transmissions. > > Furthermore with (2), RFC9759 recommends use of CONfirmable = responses > > to > > handle potential packet loss - which does not work with a flooded = pipe > > DDoS > > situation. > > > > I agree that if all can fit into one packet then this is not an = issue, > > but > > enforcing that is difficult unless there are data reduction policies > > in > > place (such as using Queries or the remainder of the data is not = sent > > (parameter/values deleted) and a response (may need new code) that > > says > > status is too large to fit into a packet or has been truncated). > > > > Another possibility is to create a new CoAP option that is = equivalent > > to > > BLOCK2 in format but does not need to work symmetrically. Here, the > > DOTS > > server sequentially sends all of the CoAP fragmented data without > > requiring > > the DOTS client to request the next block (just as fragmented IP > > packets > > would be sent). It would then be up to the DOTS client to do the = CoAP > > plain > > text block fragmentation re-assembly (again a limitation requiring > > more RAM > > on the DOTS client and garbage collection if there are missing > > packets). > > Using this new option reduces the load on the DOTS server who could = be > > serving many DOTS clients. > > > > Thoughts? > > > > Regards > > > > Jon > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 7 00:53:29 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 D44EB3A18C2; Tue, 7 Apr 2020 00:53:23 -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: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158624600381.27398.18200958068747513105@ietfa.amsl.com> Date: Tue, 07 Apr 2020 00:53:23 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-06.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: Tue, 07 Apr 2020 07:53:24 -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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Filename : draft-ietf-dots-telemetry-06.txt Pages : 93 Date : 2020-04-07 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-06 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-06 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 Tue Apr 7 01:03: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 D99C03A18B0 for ; Tue, 7 Apr 2020 01:03:44 -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, 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 usLt1hYDuPnG for ; Tue, 7 Apr 2020 01:03:43 -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 27F7F3A18AF for ; Tue, 7 Apr 2020 01:03:43 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48xKfj6Vh7zFqDr for ; Tue, 7 Apr 2020 10:03:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586246621; bh=1ow5PvwZCqZZlAhw8e0fIls/uRecmYixp0nsmYcUq5Y=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=wKUHNWhbIblh+hsSP6BTtMV95X2wRU/8hY0NE7XWDhO2IadcFqUjKnO8LFkDdzv2R 5ibd/cD3N9Z2E+tZPUChiU4ISS21P0vh96Wp3fZXRMuZmYuCC6B2lSXJjhjpsNvna/ c+heLZONGYFg+zL5+/IQr2H9qpZ34mxu5wjMcIOl08XJOGe+3HeFGptA+lQnIFw556 Jvjn9ArcrQ2TMLGhaCW+eqLqlMlUsLcMSTlZHrK2Jy4bWqyqIldfBAObuwDv8GJFX0 zVEqb5l2znbpIJTLCJrefLGPx8zW9w3oevqlurlAz5ZcK3KH9ZDQfVhOugF0UxIag0 qthwHqY8XI9ZQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48xKfj5jMVzBrLT for ; Tue, 7 Apr 2020 10:03:41 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-telemetry-06.txt Thread-Index: AQHWDLGyfVymjH6szUuLK92Wjbpd+KhtSh+Q Date: Tue, 7 Apr 2020 08:03:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148FF3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158624600381.27398.18200958068747513105@ietfa.amsl.com> In-Reply-To: <158624600381.27398.18200958068747513105@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-06.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: Tue, 07 Apr 2020 08:03:45 -0000 Hi all,=20 The main changes in this version are as follows: * add a reminder that cuid/cdid must not appear in the message body * add a reminder about the use of YANG * add a clarification about refresh of telemetry configuration * Restructure the model to fix a problem raised by Jon about access to max/= min data when no tsid is in place. * Define unit-type=20 * attack details are not modeled as an array * add new containers ton convey protocol- and port-specific telemetry data.= =20 * add a clarification about partial requests * add a clarification about the usage of per protocol and per-port metrics.= =20 * telemetry data can now be filtered using Uri-Query options * add a note about handling baseline to accommodate non-attack overloads * describe how to delete "tmids' * update the cbor/mapping tables.=20 The point about long responses is still PENDING. =20 Please review and share your comments. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mardi 7 avril 2020 09:53 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-telemetry-06.txt >=20 >=20 > 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. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Filename : draft-ietf-dots-telemetry-06.txt > Pages : 93 > Date : 2020-04-07 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal DDoS attack > mitigation. > It specifies the normal traffic baseline and attack traffic > telemetry > attributes a DOTS client can convey to its DOTS server in the > mitigation request, the mitigation status telemetry attributes a > DOTS > server can communicate to a DOTS client, and the mitigation > efficacy > telemetry attributes a DOTS client can communicate to a DOTS > server. > The telemetry attributes can assist the mitigator to choose the > DDoS > mitigation techniques and perform optimal DDoS attack mitigation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-telemetry-06 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-06 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Apr 7 04:11:44 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 1E0383A0C69; Tue, 7 Apr 2020 04:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGeA9ogT11BZ; Tue, 7 Apr 2020 04:11:31 -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 788943A0C68; Tue, 7 Apr 2020 04:11:31 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr25.francetelecom.fr (ESMTP service) with ESMTPS id 48xPqP0d0tzCqvg; Tue, 7 Apr 2020 13:11:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586257889; bh=XLmWoNokFlCJkYyTt/BI5qtSXAUXqbizdfhpknnz+UE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=xBRTYmU9OWPIqnhjXdQrSiiZSktRksPP/kxtJlI7C7AZGGtLj6k94JWmOMWGEXtpp P3QF522YIs9rotIxNngfqMt1JZPSGvWO1PnB/BSKTHlK1XaOPCAnFBN3gYjRhZlDIt x0tkcrjs/qwffKbfvNp4NFpZYnMHwwKSTdJkdDfNRUBvG9EzDUvnVYoSw+Kf/f4TmN Sik/u3/wSqUNTibwpXwhBmPTObvOb+sLVEFt04fW/e9YqRH8ctTGTpbbqDw91F4snr 5tuK4OJsiTM3kSF4Y70S90YTl9GNKkHA3ibG4AA/5xfIwftMR1tqI7Rr1zMCMfwOuX EHwntLQRTho7w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 48xPqP1KfPzDq7k; Tue, 7 Apr 2020 13:11:29 +0200 (CEST) From: To: "core@ietf.org" CC: "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AdYMzUH7Od/A8MMEToW8zPzszV9XuQ== Date: Tue, 7 Apr 2020 11:11:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031490173@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_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 11:11:33 -0000 --_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 he= re: https://mailarchive.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 t= he fragments. The observer will follow a SACK-like approach to request retr= ansmission 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 --_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

--_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_-- From nobody Tue Apr 7 06:09:57 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 8D33B3A092A; Tue, 7 Apr 2020 06:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 GlrVmfyFze7k; Tue, 7 Apr 2020 06:09:49 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA963A0928; Tue, 7 Apr 2020 06:09:48 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A7D8640142; Tue, 7 Apr 2020 15:09:46 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 43CC914B; Tue, 7 Apr 2020 15:09:45 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 08DBF381; Tue, 7 Apr 2020 15:09:45 +0200 (CEST) Received: (nullmailer pid 2764034 invoked by uid 1000); Tue, 07 Apr 2020 13:09:44 -0000 Date: Tue, 7 Apr 2020 15:09:44 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "core@ietf.org" , "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Message-ID: <20200407130944.GA2738832@hephaistos.amsuess.com> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 13:09:52 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, hello Med, I don't have full answers, but some data points (also pulling in the cited mail): > and a response (may need new code) that says status is too large to > fit into a packet or has been truncated). That an observation with blockwise would already do: If the observed resource changes to have its representation larger than the block size or MTU, it'd send the first block. > The observer will follow a SACK-like approach to request > retransmission of missing fragments. There was a draft around on non-traditional responses[1] some time ago that would provide building blocks from which a server could send follow-up blocks in an unsolicited fashion: The second block would be a message in the style of "This is a 2.05 Content response, which you would have received as a response had you requested block2 of /path". Those messages would not be ack'ed if they are NON, and the client can selectively request blocks it thinks it missed (but, in such a setup, would do that after a suitable timeout to not request something that is already in flight). That draft was not followed up on directly, but some of its ideas wound up in [2] where observe notifications are sent to a multicast group. In particular, the topic of which tokens would be usable for unsolicited responses to unicast addresses has not received the discussion it'd probably need. Kind regards Christian [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00 [2]: https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notifi= cations-02 --=20 The detailed semantics of CoAP methods are "almost, but not entirely unlike" [HHGTTG] those of HTTP methods. [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979. -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP) --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6Me5UACgkQOY0REtOk veF28Q/+NfJukV1iICMrEQwcnheVBfQcTTxr+AAlNhvtZAWwT2lNs7GceVV74CHq Xjd47f08uqPaxjHZuUD8/a8BWKum1QlfmWGzJRdXyB0oPjx5/dBtSYYS4mgpvzlu v6r883C/QWV7++WFzudxhT8fgcTMS+Pi9PbuksgdW8aqQjM3sIK0NcDqhqEOPtuE pMxgT1jLqLZrArMjJMo+EBLrEAT6b82Ctymd169NzSCelaFnIig5R4TSha8z/gOm r5fsQDRE1S5NCAbHycM3lgNvZxTVWKNqXgAJwYv+ezBuglPqy6F7qn3bzKaqsGpG UqZjj3maZy3FBeHu23YnGcbT9Qf6SER0nAtCyQuEH4dTB5GCkgv+bVD7kjbhmab2 8a/cEOoLQv8/gg4QlMxEXF8cgD075JjMj5oh2U4hpEbRG1yORk7XhCRa1cGePOp4 ZU0acZSrMABAm3siLVHK1otr0hYJc4ZfshNrog+QWzgDFJY1s+BgwAx8EX1DWqo8 qFqgLlUPdPTMe8RHZNe+2peL69uuv2fV4WaQ0pxZHJcIVW/Dx42kHbdFux3mfnOr 3i2P8KzTuvcZu12iSyT9G8HlKtRP5RRg9AhnRojRuLpOFcPDJE+9PvV5Qvflt0YI uARXIyaoT0bzAMO/LOeMZBS+a8w8REed0U65oVf7TUqGA+KiCBw= =zhM9 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From nobody Tue Apr 7 08:18: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 1B33D3A0C42; Tue, 7 Apr 2020 08:18:47 -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 r-oAboI2pnJa; Tue, 7 Apr 2020 08:18:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2203A0C46; Tue, 7 Apr 2020 08:18:44 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 Apr 2020 08:18:38 -0700 From: Jim Schaad To: , CC: 'Jon Shallow' , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 7 Apr 2020 08:18:36 -0700 Message-ID: <049201d60cef$d1299a50$737ccef0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0493_01D60CB5.24CB3780" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKc6kPPIrA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 15:18:47 -0000 ------=_NextPart_000_0493_01D60CB5.24CB3780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not believe that there is anything today that says the observer is required to do a GET to receive the next fragment in the event that it does not care about what it says. The question that sprints to mind is how should the server/client decide that it does or does not want to retrieve the entire content? Jim From: core On Behalf Of mohamed.boucadair@orange.com Sent: Tuesday, April 7, 2020 4:11 AM To: core@ietf.org Cc: Jon Shallow (supjps-ietf@jpshallow.com) ; dots@ietf.org Subject: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Hi all, We are using Observe to receive notifications during attack events. These notifications are set as NON messages for reasons specific to DDoS conditions. With DDoS telemetry information included (see draft-ietf-dots-telemetry), a notification may not fit one single message. The use of BLOCK2 is not convenient during attack times. A full description of the issue is described here: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ We are considering some mechanisms to solve this issue. One of them is to define a new BLOCK option (similar to BLOCK2) that does not require the observer to send a GET to receive the next fragment. The server will send all the fragments. The observer will follow a SACK-like 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 ------=_NextPart_000_0493_01D60CB5.24CB3780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not = believe that there is anything today that says the observer is required = to do a GET to receive the next fragment in the event that it does not = care about what it says.   The question that sprints to mind = is how should the server/client decide that it does or does not want to = retrieve the entire content?

 

Jim

 

 

From: core = <core-bounces@ietf.org> On Behalf Of = mohamed.boucadair@orange.com
Sent: Tuesday, April 7, 2020 = 4:11 AM
To: core@ietf.org
Cc: Jon Shallow = (supjps-ietf@jpshallow.com) <supjps-ietf@jpshallow.com>; = dots@ietf.org
Subject: [core] Large asynchronous notifications = under DDoS: New BLOCK Option?

 

Hi = all,

 

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

 

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

 

We are = considering some mechanisms to solve this issue. One of them is to = define a new BLOCK option (similar to BLOCK2) that does not require the = observer to send a GET to receive the next fragment. The server will = send all the fragments. The observer will follow a SACK-like 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 =

------=_NextPart_000_0493_01D60CB5.24CB3780-- From nobody Tue Apr 7 08:51: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 45B443A099F; Tue, 7 Apr 2020 08:51:19 -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, 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 lV0pOzc_tuI6; Tue, 7 Apr 2020 08:51:18 -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 B38D53A09AA; Tue, 7 Apr 2020 08:51:17 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48xX2C6T6tz1yKM; Tue, 7 Apr 2020 17:51:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586274675; bh=xY1JDBBkaKRZLlR50yODwE0Sh6ccvXciEcPDFPZ9Pho=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=q8BPTgytLdXbkHhlY5D2Vd85eO0DGhGbYYMdmFyPLXQRfzVepkfrj9zSTPF/LUIn4 I42koglugrUcpBiMkyCwZtP4luV8dhrL2yTMTuDqCQRTxH4oOEyC5OlLC6ke87ZHEC zREuHEiXk7l9WQVFWK0UJ1MvtsOtQY5NeuSNVdq3vHH/eBl1WjaAGY33dP0cyvUEqf 75kZNZq/vwwHmxVeLzS4eUTLJjcDEr1K8v3eu2pi8WPb8+W3Cjx9IhUyVCO+XwX0I0 ELeXBxsuSzR+EZXx8DnMPXVbWMNVn0K751b79IrTM+R/Ezmu86KVGe7dudxBtjY66s 6WKFJDtWGg0UQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 48xX2C6DbFzDq7f; Tue, 7 Apr 2020 17:51:15 +0200 (CEST) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "core@ietf.org" , "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDPRedOrOjDwtJU6xyqFOQUbPsA== Date: Tue, 7 Apr 2020 15:51:14 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149075C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200407130944.GA2738832@hephaistos.amsuess.com> In-Reply-To: <20200407130944.GA2738832@hephaistos.amsuess.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 15:51:20 -0000 Hi Christian, Thank you for sharing your thoughts.=20 I don't see where in the two drafts an observer can request a particular mi= ssing fragment.=20 Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mardi 7 avril 2020 15:10 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: core@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com); > dots@ietf.org > Objet=A0: Re: [core] Large asynchronous notifications under DDoS: New > BLOCK Option? >=20 > Hello Jon, hello Med, >=20 > I don't have full answers, but some data points (also pulling in the > cited mail): >=20 > > and a response (may need new code) that says status is too large to > > fit into a packet or has been truncated). >=20 > That an observation with blockwise would already do: If the observed > resource changes to have its representation larger than the block size > or MTU, it'd send the first block. >=20 > > The observer will follow a SACK-like approach to request > > retransmission of missing fragments. >=20 > There was a draft around on non-traditional responses[1] some time ago > that would provide building blocks from which a server could send > follow-up blocks in an unsolicited fashion: The second block would be > a message in the style of "This is a 2.05 Content response, which you > would have received as a response had you requested block2 of /path". >=20 > Those messages would not be ack'ed if they are NON, and the client can > selectively request blocks it thinks it missed (but, in such a setup, > would do that after a suitable timeout to not request something that > is already in flight). >=20 > That draft was not followed up on directly, but some of its ideas > wound up in [2] where observe notifications are sent to a multicast > group. In particular, the topic of which tokens would be usable for > unsolicited responses to unicast addresses has not received the > discussion it'd probably need. >=20 > Kind regards > Christian >=20 > [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00 > [2]: https://tools.ietf.org/html/draft-tiloca-core-observe-multicast- > notifications-02 >=20 >=20 > -- > The detailed semantics of CoAP methods are "almost, but not entirely > unlike" [HHGTTG] those of HTTP methods. > [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October > 1979. > -- Shelby, et al., Internet-Draft Constrained Application Protocol > (CoAP) From nobody Tue Apr 7 09:48: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 5D23F3A0EAD; Tue, 7 Apr 2020 09:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_2UQ5pdboFX; Tue, 7 Apr 2020 09:48:50 -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 079F73A0EAA; Tue, 7 Apr 2020 09:48:50 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 48xYJc5S0Lz7tqZ; Tue, 7 Apr 2020 18:48:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586278128; bh=PFNUr/DLCWdsL/Urbz4cLj2KnwQxYJyt+osuaCuzje4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=l9oVm/gviZKxWmAWKIChS+lh2m1AQjb0qs7NWCgSDoMscvIbr4RSQL2xmExJmq+ap u02XEpjvg60KtkJcUCBOnwbU/KWkbTmQZoXueJ0u+X2znQ2r6pYKduttW+SoboBpq7 uuj0Fb+x8zacyAxKRu0dzNyMl15ta5OCJVuGxBKylLFDihunLTDOjTFEMDaRkEd57o VKMWp/2uRgwqmoDTEOKpK3PWEnLckkq2ADG//CHGWOIhNk9kJnzyAOvCOtWIPorTXJ XRTCfyAVLPe+EqEgiZDRsnVb4Z1Xeh3E0IeoXSBX3Ge6VrK3XXNMGMLD0OSjEAOhW6 gqm/Wq0jq1New== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 48xYJc4GM2z1xpK; Tue, 7 Apr 2020 18:48:48 +0200 (CEST) From: To: Jim Schaad , "core@ietf.org" CC: 'Jon Shallow' , "dots@ietf.org" Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDPxoTyAJ7vdgrkKV3NX2lQCcxw== Date: Tue, 7 Apr 2020 16:48:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149082D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <049201d60cef$d1299a50$737ccef0$@augustcellars.com> In-Reply-To: <049201d60cef$d1299a50$737ccef0$@augustcellars.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_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 16:48:53 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, That can be policy based at the client side + some signal to the server. For our DOTS application, clients indicate to servers that they are (not) w= illing to receive all the content (below an excerpt of our spec): DOTS clients that are interested to receive pre- or ongoing mitigation telemetry (pre-or-ongoing-mitigation) information from a DOTS server (Section 8.2) MUST set 'server-originated-telemetry' to 'true'. And In order to signal telemetry data in a mitigation efficacy update, it is RECOMMENDED that the DOTS client has already established a DOTS telemetry setup session with the server in 'idle' time. Clients can filter out data they are interested in (Uri-Query), e.g.,. Header: GET (Code=3D0.01) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D12332" Uri-Query: "target-alias=3Dhttps1" Observe: 0 If not filter is included, all the content has to be returned to the client= : Header: GET (Code=3D0.01) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "tm" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "tmid=3D123" Observe: 0 Figure 34: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid' What is missing for us is a "BLOCK2"-Like option to send all fragments with= out waiting for a GET + retrieval of missing fragments (if any). Cheers, Med De : Jim Schaad [mailto:ietf@augustcellars.com] Envoy=E9 : mardi 7 avril 2020 17:19 =C0 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org Cc : 'Jon Shallow'; dots@ietf.org Objet : RE: [core] Large asynchronous notifications under DDoS: New BLOCK O= ption? I do not believe that there is anything today that says the observer is req= uired to do a GET to receive the next fragment in the event that it does no= t care about what it says. The question that sprints to mind is how shoul= d the server/client decide that it does or does not want to retrieve the en= tire content? Jim From: core On Behalf Of mohamed.boucadair@orange.co= m Sent: Tuesday, April 7, 2020 4:11 AM To: core@ietf.org Cc: Jon Shallow (supjps-ietf@jpshallow.com) ; do= ts@ietf.org Subject: [core] Large asynchronous notifications under DDoS: New BLOCK Opti= on? 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 he= re: https://mailarchive.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 t= he fragments. The observer will follow a SACK-like approach to request retr= ansmission 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 --_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

That can be policy based at the client side + some signal= to the server.

 

For our DOTS application, clients indicate to servers that th= ey are (not) willing to receive all the content (below an excerpt of our sp= ec):

 

   DOTS clients that are interested to receive p= re- or ongoing mitigation

   telemetry (pre-or-ongoing-mitigation) informa= tion from a DOTS server

   (Section 8.2) MUST set 'server-orig= inated-telemetry' to 'true'.

 

And

 

   In order to signal telemetry data in a mitigation efficac=
y update, it
   is RECOMMENDED that the DOTS client has already establish=
ed a DOTS
   telemetry setup session with the server in 'idle' time.

 

 

Clients can filter out data they are interested in (Uri-Query= ), e.g.,.

 

   Header: GET (Code=3D0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "mitigate"
   Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"<=
/o:p>
   Uri-Path: "mid=3D12332"
   Uri-Query: "target-alias=3Dhttps1&=
quot;
   Observe: 0

 

If not filter is included, all the content has to be returned= to the client:

 

   Header: GET (Code=3D0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"<=
/o:p>
   Uri-Path: "tmid=3D123"
   Observe: 0
 
    Figure 34: GET to Subscribe to Telemetry Asynchrono=
us Notifications
           &nbs=
p;            &=
nbsp;  for a Specific 'tmid'

 

What is missing for us is a “BLOCK2”-Like option = to send all fragments without waiting for a GET + retrieval of missing = fragments (if any).

 

Cheers,

Med

 

De : Jim Schaad [mailto:ietf@augustcellars.com]
Envoy=E9 : mardi 7 avril 2020 17:19
=C0 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org
Cc : 'Jon Shallow'; dots@ietf.org
Objet : RE: [core] Large asynchronous notifications under DDoS:= New BLOCK Option?

 

I do not believe that there is anything today that s= ays the observer is required to do a GET to receive the next fragment in th= e event that it does not care about what it says.   The question = that sprints to mind is how should the server/client decide that it does or does not want to retrieve the entire content?<= /o:p>

 

Jim

 

 

From: core <core-bounces@ietf.org> O= n Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, April 7, 2020 4:11 AM
To: core@ietf.org
Cc: Jon Shallow (supjps-ietf@jpshallow.com) <supjps-ietf@jpshallo= w.com>; dots@ietf.org
Subject: [core] Large asynchronous notifications under DDoS: New BLO= CK 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

--_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_-- From nobody Tue Apr 7 09:50: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 083043A0EC1; Tue, 7 Apr 2020 09:50: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, 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 (1024-bit key) header.d=gmx.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 ohPWqocywtQi; Tue, 7 Apr 2020 09:50:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 BE1A23A0EBD; Tue, 7 Apr 2020 09:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586278203; bh=ILiRS55BpU55sdLJLxrv12R+4F2XOmjFKm8b0WuGy30=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=cSVbzKT/1/U2duaPQaZFKgrY2UV3uR90khbT88YgB2zhFU5D1tSUVpsnmw89o/a8l DciqxlP3TC15UONSMsvovC9dfiiJUHf8U2IRd7gNQylsOXkyTsLTISuzp9qeInevJt no3EBKzLhxWA4IS8aB4UDd44s44sD8lJammM49eI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MD9X9-1jUtpa1skj-0099n6; Tue, 07 Apr 2020 18:50:03 +0200 To: mohamed.boucadair@orange.com, "core@ietf.org" Cc: "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Achim Kraus Message-ID: <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> Date: Tue, 7 Apr 2020 18:50:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:mPFjpV4HB6bc1Em4PJbRRTBjDTwakg/BFkx3yMW1Tb7ObxrRM/g HmTpNZzdIPeiBg08PJQZKkaUzFS1BGcEXxu1wRnZrSzzswwmYCs6KIjQxDD3ToIJE1yqZfq Vk732vhUmidCsMubMvdY9hU8UffYggX6zXKHppp+GvSgbXm/B7FKnYdb7g8Q3Sqsc/HnR94 HiHyjNROn8BmV3Iis5gGw== X-UI-Out-Filterresults: notjunk:1;V03:K0:zO8W3e4ORhY=:P0GBs1ZNtHBgbPxHDHFXIW 1ri3/7nfeqEgPFbmzGAwJUAcSgh7d4Eleqkhz1wBY8zs7vgVKCBTkxPwwCMMZnVM0xzP8k70a QUJu1SeDhCSysIgT/RUsG3asUFkMLV38Bobq7E7Ff7qznCLfvuEeYtdbivmxWKbqG6GR2UgPM 7KNsd0xa4gBi+8+V3aWMn5k47RadhrMGDeIQnXJfazn9fKp8jDml/VaCrbB1cHLvOqW51jviN 5yp8bwyudzA10C9ih/MysARe0Oa488X04zFkTn9AONK3VcqDqYOdLFpOjyVDR/kZ5uF+1mSA1 AfBKxhqYZ4N+NMvkDM0qMCuDR+kFRrAtrObr1HcnPGMFYV7mP4Bnppjl+zv9PSDn8M+gvQMrF zNohcEZYUb/snx15HnJm3HR0sR/VZ4J701vSwvcNPxyTkRQvrJGW3gAGWnvh8zN9fOx1dg5WA AthQDxc/sFCYJWdzNKgIxGNI/0Tt7OinBU4XahogVZlHqDC7elmQoAy3+qiTqu2GkSbWXz3Qt r24oXy51WtE9fl8lGjO4lmwGAC6aGm043k4gUGRQPf3IwbV600wKDVQDOmBK38YLFV4lDO79s TqEcqlevJOc1mFW0nJqEA/4xhVcXUZHK9YIfM/gFKdbmPTsxsRADXzfCacfKepHZoiV3BWQUK L2yjLh+u74tmiv598hVIcbVGMM6WbxLu82F8DwETZXAweXu3q/RvfXjFOa5SvSyFrjrsxnwqy BqITQz+jSCCvhDI1papz653ya20781w8aTE9yZXEC08CP8SKQLy1fjZ6VjvBOfCYIa5gqvm/4 3a6bUSrvrOJqH66vnEGCs+6w9t+gbug7jBOk1egIY4pEpNUhMOq8A8kyoUW/c6fMnMSf5Q+rO dX4cm4a+7trisIS9dKO3Mc0kwGJYKBY6WEDRwCWgGyI16BdlqXI2i5updMvVgkbKoF0jsixwO yreURufRCTotWLwzt3TTNQDspfC1l35dtjFZrzY8dkNjEZwXl7n28mFSbunAJZD7v6nlaCSbW 4/hLojUCGJkgNVM90L8WXO1HZELpIEgNq1fxdFo+okiP5ew+KBFbYXnvYurogchw/PsKVjrxm Rvk6J0YAabSJCXaxjbpbzN9evF39yQHIWK+x7TYWYUENW00+NJygIuWWjJUuyPGIExXVYh6OP GdkcByP1fsSNsL0L2Sjv7AwF5D5Dz87XHtQTOYG3NMjXIHIEyywFbOxAqyAmuzesNzL3GosT3 5rPgEBOfETYWktdys Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 16:50:12 -0000 Hi Med, I think, not all assumption and requirements are clear to everyone. I guess, your mission is to send a couple of "block" messages, but without getting requested for the next-blocks, because the node is under attack and already receiving too much. Therefore the SACK will be used a little later as "cleanup"/"collect lefts". My first idea about that was, that sending the "block-flush" just creates the next attack. But, if you sure, that this doesn't happen, then such an approach may help in that special situation. I'm not sure, if you assume, that in the most cases all blocks will make it to the destination when sending them. That may also depend on the assumed number of blocks. If it's not assumed, that all block will be received, your payload should be encoded in a way, that you could decode the received blocks, even if some blocks are missing. If that number is not too large, maybe a "blockwise with NSTART-X" will also do it. Especially if DTLS is used, it may be possible to concat the "ACK/next blocks" into one package (with multiple records). AFAIK, that would require changes in implementations, which optimizes the deduplication base on a strict sequence of blocks, but the difference should be not too large. best regards Achim Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > Hi all, > > We are using Observe to receive notifications during attack events. > These notifications are set as NON messages for reasons specific to DDoS > conditions. > > With DDoS telemetry information included (see > draft-ietf-dots-telemetry), a notification may not fit one single > message. The use of BLOCK2 is not convenient during attack times. A full > description of the issue is described here: > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ > > We are considering some mechanisms to solve this issue. One of them is > to define a new BLOCK option (similar to BLOCK2) that does not require > the observer to send a GET to receive the next fragment. The server will > send all the fragments. The observer will follow a SACK-like 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 > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue Apr 7 10:41:35 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 1D8403A09D4; Tue, 7 Apr 2020 10:41:35 -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, 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 ugjAWRvEyuTn; Tue, 7 Apr 2020 10:41:33 -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 619B03A09C5; Tue, 7 Apr 2020 10:41:33 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 48xZTR44GRz8slB; Tue, 7 Apr 2020 19:41:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586281291; bh=NnTKUNempGvh7z/MhbD9tS/0qCskKu2X5UPkotvZgIs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=eVz/KFEf+d5yBtYUdHD6YO7v7GeZCGd3D9iRFkQwmtxD4/JczoFhSaRPj9RbTLg6d uYOGLMFXC+YdeCx7hKGlEH8p3TKYb8xlG8v6EVTzIGZ/Of6i/5PT60IVyNOC8jMK7R 4sMkHQ4zKTpvDUS0zGtU/n7KLpcj2O9HMTx2/GrF4BHAx7QkxGrqt50tk33tmBJi8G hyLOvgV/8/r6+42ajV47bmplmmeZGJZcCMlwqhjLvJ7lDjbWW6Xwk7QLmvgo9ijljo +aoj8jsLbLn2WDRYs2UKB41DXnuSBqxQQ5OMofGBAYGazyev18ZNk2yeTY2XCsIz5P Q55Dj+CgaqYtQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48xZTR2nvfzCqkn; Tue, 7 Apr 2020 19:41:31 +0200 (CEST) From: To: Achim Kraus , "core@ietf.org" CC: "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDQPFc2Cf8aWOkUeEiB2evm8ivQ== Date: Tue, 7 Apr 2020 17:41:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> In-Reply-To: <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> 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] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 17:41:35 -0000 Hi Achim, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Achim Kraus [mailto:achimkraus@gmx.net] > Envoy=E9=A0: mardi 7 avril 2020 18:50 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; core@ietf.org > Cc=A0: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > Objet=A0: Re: [core] Large asynchronous notifications under DDoS: New > BLOCK Option? >=20 > Hi Med, >=20 > I think, not all assumption and requirements are clear to everyone. >=20 [Med] We are using CoAP for signaling DDoS attacks and for seeking help fro= m a DDoS mitigator. The mitigation signal itself is compact as we do have a= requirement that the signal channel survive under extreme DDoS conditions.= We do have a mechanism to maintain the signal alive, to detect when it is = lost and then to recover asap.=20 We are now designing an extension to the base signaling that allows to shar= e knowledge of attacks for better coordination and efficient mitigation. To= that aim, we need to signal DDoS telemetry data between our DOTS agents (C= oAP endpoints). =20 > I guess, your mission is to send a couple of "block" messages, but > without getting requested for the next-blocks, because the node is > under > attack and already receiving too much. Therefore the SACK will be used > a > little later as "cleanup"/"collect lefts". [Med] Yes. =20 >=20 > My first idea about that was, that sending the "block-flush" just > creates the next attack. But, if you sure, that this doesn't happen, > then such an approach may help in that special situation. [Med] Yes.=20 >=20 > I'm not sure, if you assume, that in the most cases all blocks will > make > it to the destination when sending them. That may also depend on the > assumed number of blocks. If it's not assumed, that all block will be > received, your payload should be encoded in a way, that you could > decode > the received blocks, even if some blocks are missing. [Med] This is will be nice to have. This might be managed at the applicatio= n (DOTS) level but there are some challenges as well (make sure that the cr= afted data will fit a single DTLS packet). >=20 > If that number is not too large, maybe a "blockwise with NSTART-X" > will > also do it. Especially if DTLS is used, it may be possible to concat > the > "ACK/next blocks" into one package (with multiple records). AFAIK, > that > would require changes in implementations, which optimizes the > deduplication base on a strict sequence of blocks, but the difference > should be not too large. >=20 > best regards > Achim >=20 >=20 > Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > > Hi all, > > > > We are using Observe to receive notifications during attack events. > > These notifications are set as NON messages for reasons specific to > DDoS > > conditions. > > > > With DDoS telemetry information included (see > > draft-ietf-dots-telemetry), a notification may not fit one single > > message. The use of BLOCK2 is not convenient during attack times. A > full > > description of the issue is described here: > > > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4 > / > > > > We are considering some mechanisms to solve this issue. One of them > is > > to define a new BLOCK option (similar to BLOCK2) that does not > require > > the observer to send a GET to receive the next fragment. The server > will > > send all the fragments. The observer will follow a SACK-like > 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 > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > From nobody Tue Apr 7 10:58:59 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 ADCE53A1BD6; Tue, 7 Apr 2020 10:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OC99_BrR1nyk; Tue, 7 Apr 2020 10:58:42 -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 8AB6A3A0B1B; Tue, 7 Apr 2020 10:56:20 -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 1jLsSN-0006Sq-8N; Tue, 07 Apr 2020 18:56:15 +0100 From: "Jon Shallow" To: "'Achim Kraus'" , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 7 Apr 2020 18:56:21 +0100 Message-ID: <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no82o+kI84A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 17:58:49 -0000 Hi Achim, To add to Med's inline comments, the use case that we are trying to = solve is as follows. We are trying to send telemetry information from a server to a unicast client which has the potential to exceed the size of IP packet (possibly multiple times too large). The environment that this telemetry information is going to be = transmitted in will be where Distributed Denial of Service (DDoS) attacks are taking place and so there is a high chance that network pipes will be running = at or near capacity and hence there is likely to be high packet loss. It is likely that the direction of the telemetry data is the same as that of = the packet loss. This telemetry is an additional tool for passing information about how mitigations of these DDoS attacks are being effective so that decisions = can be taken as to how better to mitigate the DDoS situation. This is = making use of the DDoS Open Threat Signaling protocol (DOTS) described in = RFC8612 with other drafts for components of this protocol in the final stages of becoming RFCs ( https://tools.ietf.org/wg/dots/ ). While not desirable, it is acceptable if the client is unable to receive = the telemetry data (out of band mechanisms such as phone calls can be used = in slow time if needed for tuning against attacks) but we would like to maximize the possibility of the telemetry data getting through. Currently with other data and small amounts of telemetry, the GET = response or Observe data can safely be sent off from the server and the client = may or may not get it as we are using NON-confirmable. PUT (which has small amounts of data) and DELETE are also sent as NON-confirmable - and the client handles things if there is not seen a 2.XX etc. response to the PUT/DELETE. This issue is when the data is too large to fit into a single packet - = we currently use the CoAP BLOCK2 option which works fine under normal = traffic conditions, but relies on the client synchronously requesting the next = block of data. We currently are doing this as NON-confirmable so a loss of a block of data causes the transfer to stall with the need to do garbage collection at a later point in time ion the server. Using CONfirmable causes everything to slow right down with the lossy network and prevents = the next CON transmission for a long time as NSTART is 1. The data is CBOR based on YANG with the YANG parameters two-way mapped = into integers to give as much CBOR data reduction as possible, so cannot save = any space there. It is theoretically possible to reduce the amount of = telemetry data by only asking for subsets of information as Med has referred to in this email trail. It is possible to solve the issue using IP fragmentation and let the = client re-assemble everything, but this is not ideal in a lossy network and = there is no way to ask for a particular IP fragment to be re-transmitted. If there was a new CoAP option - let's call it NONBLOCK2, which the = server uses to send the all the data packets without waiting for the GET = request of the next block (only difference compared with BLOCK2). If the client = does not see all the blocks after a timeout, it can then request the missing blocks by using one or more of the NONBLOCK2 options in a new GET = request - or just wait until the next GET / Observe response. This may be a way = to move forward if we cannot solve the issue in another way. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 07 April 2020 18:42 > To: Achim Kraus; core@ietf.org > Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Achim, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Achim Kraus [mailto:achimkraus@gmx.net] > > Envoy=E9=A0: mardi 7 avril 2020 18:50 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; core@ietf.org > > Cc=A0: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > > Objet=A0: Re: [core] Large asynchronous notifications under DDoS: = New > > BLOCK Option? > > > > Hi Med, > > > > I think, not all assumption and requirements are clear to everyone. > > >=20 > [Med] We are using CoAP for signaling DDoS attacks and for seeking = help > from a DDoS mitigator. The mitigation signal itself is compact as we = do have > a requirement that the signal channel survive under extreme DDoS > conditions. We do have a mechanism to maintain the signal alive, to = detect > when it is lost and then to recover asap. >=20 > We are now designing an extension to the base signaling that allows to > share knowledge of attacks for better coordination and efficient mitigation. > To that aim, we need to signal DDoS telemetry data between our DOTS > agents (CoAP endpoints). >=20 > > I guess, your mission is to send a couple of "block" messages, but > > without getting requested for the next-blocks, because the node is > > under > > attack and already receiving too much. Therefore the SACK will be = used > > a > > little later as "cleanup"/"collect lefts". >=20 > [Med] Yes. >=20 > > > > My first idea about that was, that sending the "block-flush" just > > creates the next attack. But, if you sure, that this doesn't happen, > > then such an approach may help in that special situation. >=20 > [Med] Yes. >=20 > > > > I'm not sure, if you assume, that in the most cases all blocks will > > make > > it to the destination when sending them. That may also depend on the > > assumed number of blocks. If it's not assumed, that all block will = be > > received, your payload should be encoded in a way, that you could > > decode > > the received blocks, even if some blocks are missing. >=20 > [Med] This is will be nice to have. This might be managed at the application > (DOTS) level but there are some challenges as well (make sure that the > crafted data will fit a single DTLS packet). >=20 > > > > If that number is not too large, maybe a "blockwise with NSTART-X" > > will > > also do it. Especially if DTLS is used, it may be possible to concat > > the > > "ACK/next blocks" into one package (with multiple records). AFAIK, > > that > > would require changes in implementations, which optimizes the > > deduplication base on a strict sequence of blocks, but the = difference > > should be not too large. > > > > best regards > > Achim > > > > > > Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > > > Hi all, > > > > > > We are using Observe to receive notifications during attack = events. > > > These notifications are set as NON messages for reasons specific = to > > DDoS > > > conditions. > > > > > > With DDoS telemetry information included (see > > > draft-ietf-dots-telemetry), a notification may not fit one single > > > message. The use of BLOCK2 is not convenient during attack times. = A > > full > > > description of the issue is described here: > > > > > > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW > eP4 > > / > > > > > > We are considering some mechanisms to solve this issue. One of = them > > is > > > to define a new BLOCK option (similar to BLOCK2) that does not > > require > > > the observer to send a GET to receive the next fragment. The = server > > will > > > send all the fragments. The observer will follow a SACK-like > > 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 > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 7 12:04:33 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 7A1433A0770; Tue, 7 Apr 2020 12:04:29 -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 (1024-bit key) header.d=gmx.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 cvtIhkSkEgaz; Tue, 7 Apr 2020 12:04:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 8D1393A0EEE; Tue, 7 Apr 2020 12:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586286242; bh=GpXgLsGVG8ZrsqgNB4ishmasepQ84fcJoQLLfKPvv1c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=WPEqGYii1y+cBhMTBxLo19dG7YlaGY6tReLoVTE2YLPrGt2t1HZZZP8PLx3/6G4P4 wUCHWr4NxLUsmloBTlq9A/HbslXUT352o+Emh1mmAG3LMrvQhkAzCRZ/rc/MPFdMKb Y2vbHvLSBcAVnsUy1xjfjPRBnNN2FzBwE14ZJIKY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M3DO3-1jIrFM2o9d-003gjp; Tue, 07 Apr 2020 21:04:01 +0200 To: Jon Shallow , mohamed.boucadair@orange.com, core@ietf.org, dots@ietf.org References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> From: Achim Kraus Message-ID: Date: Tue, 7 Apr 2020 21:04:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ReQsGiKjogqOLdcmututzFiDaI6m87yVxp4GLMLZ48fSJG85GKU yFHCwrBzAYjkR4VAdyK7SdrIYJQXxW7sLerNfeg3NM1BWsCmXr+AmaNai99xr10iOmg5j6E mu2B7mTTM1odU5gHnzw1/o6tFjXB5eFdquYutOr/bkeh71CplYTT/hezHhzjs3Lw18nkIgV 34wEig3KzBhuIT/TyCamA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Sh5UeQIoZwE=:///5Wlj0wKbtU1XgVnPAm5 5fzsIQUSEYwVX2fjjUKdHIhkV9gC7x8/ILngyteAMRGl+9eZU70+RTdQf93GOIIZB7yMZB4o3 wY6uc7hI5CaMcpJqwk21iF5zhIFIu+LxI17P5U5RhixVyPppjRt1bm+vgqmhCSONuEEc/QUDl 1HIX/9CNqkq9IjWK7nrnPP6t//I6HjdLANlmlWExUn6GVnc9fgFRFX9JRiNBCA1qpNnov0hLI 3A8aqzCicT3EcMw2kO00EBbH4AQ00iLM+h/DC7ZtDvABsVlJJ3OffKHrpuWd1+Ri5fluuUlbg MIh2Aa4bbakshQ8r7GY/OlWDAhKq5z5viDjHfd7T9uw1z6uqZjShvXZy7KQwhZpc+gdGBxdSx RbrTCOU3akU5wF/cTH3vd4Qtsx6A18m46kP2ztl/P3JD9SMpBk0rj6hKZRZoRKkMO6ufMADr5 AXqDR5WRGE4dN82VKrWilnAzUG/7RWfrLZdv+hOJmoUKxwI/pO3N0hIrx3oFtp4BiSwdlcIcD cqp0AvI/ztBVwEXwTsioZiIO5qzEFPamNvQFMRKfDaph3K+qYVdT9F3TSAsYgn2lWrPW7LD/j oRhWq4XKrSAww3ZXBpkmm3zkKQuzhsqOBltU/wOgp4BN6maskTDMvGdaQGnXUawAtxMLVi1wN bKyYXgwNGy/sgvPjqyocYbNrEQjV/B8HlOcSMAwycNB+MtvrfbIm4ExjHRn5jSXIzw4CZnxMN EHmZeRSTz/V1HigXbQuJtkZi9wT923YkhKbXTGMszQfehT+AIlVuOk+XFrusdll+cYWue0qO7 G1canXuIbZ++/lbVjCiuuYtuCTC0y1ZB7GjJrAzeRvK53v+7U87Nz9dUoUF70zXhz8rUQjREg wGI7OpOoBEIsdBNRTeQeJh+2fXfmiC0jofgYa68P+8tr12lVdhUKUwVM9cJ9NleIq86m5jC3L CvWFZXWZOfeE4D6YE7IjHJPm0qjfrvghUG6jDOz9vVJOwHZxkCOF5Awwri9av+vkcP0MM1yHF tn6otzpnYM3BdIcqBeOtmoi7FZwFuf9iVJAUtX3WhDiVclrTaHysxPF+bA2xCuNkedHzDnPeM 1W0cZPkpRMZSchcX+VVvAkcnHANuYwliCD/SrwUQpRswn/ohu/1gCapsCOAgs9Fx27FPl54zD Xis5ykVb6+L6JPM5sn4tXeRiKxQjk9G0RyiJLkvKKonOTw8fEj+vpq/WAIsUNv4s8rTxQt8Ds lJCQ2hnziteOfXG56 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 19:04:30 -0000 Hi Jon, I'm still not sure, if such an approach would make sense: - if multiple blocks are required without gaps - the package loss is high =3D> that ends up in not receiving any "large payload" at all. FMPOV, the first thing to ensure is, that the "large payload" gets split into "application blocks", which could be processed even when other application blocks are missing. I would also not assume, that a "in between proxies" will be able to process blockwise resources with gaps. So I'm not sure, why observer/notify is used. If it should be used, (and a proxy will not work,) then you may consider to "misuse" the notifies and send your "application blocks" just in multiple notifies (each application block in one notify, without droping "old" notifies, because they are not old :-) ). In my opinion that would require less changes to existing implementations than introduce a "blockwise without next". In the end, it would be interesting, if such a improvement really pays off. Using some nodes with standard blockwise and others with the new one should show the benefit. It would be great, if you then report your numbers. best regards Achim Am 07.04.20 um 19:56 schrieb Jon Shallow: > Hi Achim, > > To add to Med's inline comments, the use case that we are trying to solv= e is > as follows. > > We are trying to send telemetry information from a server to a unicast > client which has the potential to exceed the size of IP packet (possibly > multiple times too large). > > The environment that this telemetry information is going to be transmitt= ed > in will be where Distributed Denial of Service (DDoS) attacks are taking > place and so there is a high chance that network pipes will be running a= t or > near capacity and hence there is likely to be high packet loss. It is > likely that the direction of the telemetry data is the same as that of t= he > packet loss. > > This telemetry is an additional tool for passing information about how > mitigations of these DDoS attacks are being effective so that decisions = can > be taken as to how better to mitigate the DDoS situation. This is makin= g > use of the DDoS Open Threat Signaling protocol (DOTS) described in RFC86= 12 > with other drafts for components of this protocol in the final stages of > becoming RFCs ( https://tools.ietf.org/wg/dots/ ). > > While not desirable, it is acceptable if the client is unable to receive= the > telemetry data (out of band mechanisms such as phone calls can be used i= n > slow time if needed for tuning against attacks) but we would like to > maximize the possibility of the telemetry data getting through. > > Currently with other data and small amounts of telemetry, the GET respon= se > or Observe data can safely be sent off from the server and the client ma= y or > may not get it as we are using NON-confirmable. PUT (which has small > amounts of data) and DELETE are also sent as NON-confirmable - and the > client handles things if there is not seen a 2.XX etc. response to the > PUT/DELETE. > > This issue is when the data is too large to fit into a single packet - w= e > currently use the CoAP BLOCK2 option which works fine under normal traff= ic > conditions, but relies on the client synchronously requesting the next b= lock > of data. We currently are doing this as NON-confirmable so a loss of a > block of data causes the transfer to stall with the need to do garbage > collection at a later point in time ion the server. Using CONfirmable > causes everything to slow right down with the lossy network and prevents= the > next CON transmission for a long time as NSTART is 1. > > The data is CBOR based on YANG with the YANG parameters two-way mapped i= nto > integers to give as much CBOR data reduction as possible, so cannot save= any > space there. It is theoretically possible to reduce the amount of telem= etry > data by only asking for subsets of information as Med has referred to in > this email trail. > > It is possible to solve the issue using IP fragmentation and let the cli= ent > re-assemble everything, but this is not ideal in a lossy network and the= re > is no way to ask for a particular IP fragment to be re-transmitted. > > If there was a new CoAP option - let's call it NONBLOCK2, which the serv= er > uses to send the all the data packets without waiting for the GET reques= t of > the next block (only difference compared with BLOCK2). If the client do= es > not see all the blocks after a timeout, it can then request the missing > blocks by using one or more of the NONBLOCK2 options in a new GET reques= t - > or just wait until the next GET / Observe response. This may be a way t= o > move forward if we cannot solve the issue in another way. > > Regards > > Jon > >> -----Original Message----- >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com >> Sent: 07 April 2020 18:42 >> To: Achim Kraus; core@ietf.org >> Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: >> New BLOCK Option? >> >> Hi Achim, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De=C2=A0: Achim Kraus [mailto:achimkraus@gmx.net] >>> Envoy=C3=A9=C2=A0: mardi 7 avril 2020 18:50 >>> =C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN; core@ietf.org >>> Cc=C2=A0: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >>> Objet=C2=A0: Re: [core] Large asynchronous notifications under DDoS: N= ew >>> BLOCK Option? >>> >>> Hi Med, >>> >>> I think, not all assumption and requirements are clear to everyone. >>> >> >> [Med] We are using CoAP for signaling DDoS attacks and for seeking help >> from a DDoS mitigator. The mitigation signal itself is compact as we do > have >> a requirement that the signal channel survive under extreme DDoS >> conditions. We do have a mechanism to maintain the signal alive, to det= ect >> when it is lost and then to recover asap. >> >> We are now designing an extension to the base signaling that allows to >> share knowledge of attacks for better coordination and efficient > mitigation. >> To that aim, we need to signal DDoS telemetry data between our DOTS >> agents (CoAP endpoints). >> >>> I guess, your mission is to send a couple of "block" messages, but >>> without getting requested for the next-blocks, because the node is >>> under >>> attack and already receiving too much. Therefore the SACK will be used >>> a >>> little later as "cleanup"/"collect lefts". >> >> [Med] Yes. >> >>> >>> My first idea about that was, that sending the "block-flush" just >>> creates the next attack. But, if you sure, that this doesn't happen, >>> then such an approach may help in that special situation. >> >> [Med] Yes. >> >>> >>> I'm not sure, if you assume, that in the most cases all blocks will >>> make >>> it to the destination when sending them. That may also depend on the >>> assumed number of blocks. If it's not assumed, that all block will be >>> received, your payload should be encoded in a way, that you could >>> decode >>> the received blocks, even if some blocks are missing. >> >> [Med] This is will be nice to have. This might be managed at the > application >> (DOTS) level but there are some challenges as well (make sure that the >> crafted data will fit a single DTLS packet). >> >>> >>> If that number is not too large, maybe a "blockwise with NSTART-X" >>> will >>> also do it. Especially if DTLS is used, it may be possible to concat >>> the >>> "ACK/next blocks" into one package (with multiple records). AFAIK, >>> that >>> would require changes in implementations, which optimizes the >>> deduplication base on a strict sequence of blocks, but the difference >>> should be not too large. >>> >>> best regards >>> Achim >>> >>> >>> Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: >>>> Hi all, >>>> >>>> We are using Observe to receive notifications during attack events. >>>> These notifications are set as NON messages for reasons specific to >>> DDoS >>>> conditions. >>>> >>>> With DDoS telemetry information included (see >>>> draft-ietf-dots-telemetry), a notification may not fit one single >>>> message. The use of BLOCK2 is not convenient during attack times. A >>> full >>>> description of the issue is described here: >>>> >>> >> https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW >> eP4 >>> / >>>> >>>> We are considering some mechanisms to solve this issue. One of them >>> is >>>> to define a new BLOCK option (similar to BLOCK2) that does not >>> require >>>> the observer to send a GET to receive the next fragment. The server >>> will >>>> send all the fragments. The observer will follow a SACK-like >>> 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 >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > From nobody Tue Apr 7 13:01:38 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 116183A0A5D; Tue, 7 Apr 2020 13:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rGlDRCejN5Ck; Tue, 7 Apr 2020 13:01:05 -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 DE2FB3A1051; Tue, 7 Apr 2020 13:01:04 -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 1jLuP8-0006XG-8E; Tue, 07 Apr 2020 21:01:02 +0100 From: "Jon Shallow" To: "'Achim Kraus'" , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> In-Reply-To: Date: Tue, 7 Apr 2020 21:01:08 +0100 Message-ID: <01ad01d60d17$470b9a80$d522cf80$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWqNx+MCA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 20:01:08 -0000 Hi Achim, It is good to get this feedback. Please see inline Jon1> Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus > Sent: 07 April 2020 20:04 > To: Jon Shallow; mohamed.boucadair@orange.com; core@ietf.org; > dots@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Jon, >=20 > I'm still not sure, if such an approach would make sense: > - if multiple blocks are required without gaps > - the package loss is high > =3D> that ends up in not receiving any "large payload" at all. Jon> The packet loss should be transitory in that if the DDoS Mitigation = is effective and reduces the rate of the DDoS Attack through the pipe = normal (certainly DOTS) service is resumed. DOTS needs to be able to = continue with limiting working with high packet loss as "PUT new = mitigation request" are still likely to get through. >=20 > FMPOV, the first thing to ensure is, that the "large payload" gets = split > into "application blocks", which could be processed even when other > application blocks are missing. Jon> We are also trying to do this as well, but it is not that = straightforward. >=20 > I would also not assume, that a "in between proxies" will be able to > process blockwise resources with gaps. Jon> In the DOTS case, we have the concept of DOTS gateways where the = DOTS CoAP server and DOTS CoAP client stacks are fully terminated making = things easier here. This is a good point though and needs to be worked = through. > So I'm not sure, why > observer/notify is used. If it should be used, (and a proxy will not > work,)=20 Jon> I don't quite follow why a proxy will not work unless you are = referring to blockwise resources with gaps. > then you may consider to "misuse" the notifies and send your > "application blocks" just in multiple notifies (each application block > in one notify, without droping "old" notifies, because they are not = old > :-) ). In my opinion that would require less changes to existing > implementations than introduce a "blockwise without next". Jon> It may make for less changes, but I was expecting the NONBLOCK2 = option to be handled within the application rather than at the CoAP = layer. In the DOTS case, server enhanced Telemetry information sending = has to be explicitly enabled by the client so existing implementations = will not get broken. >=20 > In the end, it would be interesting, if such a improvement really pays > off. Using some nodes with standard blockwise and others with the new > one should show the benefit. It would be great, if you then report = your > numbers. Jon> I will see what I can come up with here. A good suggestion. It = may take a while though as I have only partially got the DOTS telemetry = draft extensions coded. ~Jon >=20 > best regards > Achim >=20 > Am 07.04.20 um 19:56 schrieb Jon Shallow: > > Hi Achim, > > > > To add to Med's inline comments, the use case that we are trying to = solve > is > > as follows. > > > > We are trying to send telemetry information from a server to a = unicast > > client which has the potential to exceed the size of IP packet = (possibly > > multiple times too large). > > > > The environment that this telemetry information is going to be > transmitted > > in will be where Distributed Denial of Service (DDoS) attacks are = taking > > place and so there is a high chance that network pipes will be = running at or > > near capacity and hence there is likely to be high packet loss. It = is > > likely that the direction of the telemetry data is the same as that = of the > > packet loss. > > > > This telemetry is an additional tool for passing information about = how > > mitigations of these DDoS attacks are being effective so that = decisions can > > be taken as to how better to mitigate the DDoS situation. This is = making > > use of the DDoS Open Threat Signaling protocol (DOTS) described in > RFC8612 > > with other drafts for components of this protocol in the final = stages of > > becoming RFCs ( https://tools.ietf.org/wg/dots/ ). > > > > While not desirable, it is acceptable if the client is unable to = receive the > > telemetry data (out of band mechanisms such as phone calls can be = used > in > > slow time if needed for tuning against attacks) but we would like to > > maximize the possibility of the telemetry data getting through. > > > > Currently with other data and small amounts of telemetry, the GET > response > > or Observe data can safely be sent off from the server and the = client may > or > > may not get it as we are using NON-confirmable. PUT (which has = small > > amounts of data) and DELETE are also sent as NON-confirmable - and = the > > client handles things if there is not seen a 2.XX etc. response to = the > > PUT/DELETE. > > > > This issue is when the data is too large to fit into a single packet = - we > > currently use the CoAP BLOCK2 option which works fine under normal > traffic > > conditions, but relies on the client synchronously requesting the = next > block > > of data. We currently are doing this as NON-confirmable so a loss = of a > > block of data causes the transfer to stall with the need to do = garbage > > collection at a later point in time ion the server. Using = CONfirmable > > causes everything to slow right down with the lossy network and = prevents > the > > next CON transmission for a long time as NSTART is 1. > > > > The data is CBOR based on YANG with the YANG parameters two-way > mapped into > > integers to give as much CBOR data reduction as possible, so cannot = save > any > > space there. It is theoretically possible to reduce the amount of = telemetry > > data by only asking for subsets of information as Med has referred = to in > > this email trail. > > > > It is possible to solve the issue using IP fragmentation and let the = client > > re-assemble everything, but this is not ideal in a lossy network and = there > > is no way to ask for a particular IP fragment to be re-transmitted. > > > > If there was a new CoAP option - let's call it NONBLOCK2, which the = server > > uses to send the all the data packets without waiting for the GET = request > of > > the next block (only difference compared with BLOCK2). If the = client does > > not see all the blocks after a timeout, it can then request the = missing > > blocks by using one or more of the NONBLOCK2 options in a new GET > request - > > or just wait until the next GET / Observe response. This may be a = way to > > move forward if we cannot solve the issue in another way. > > > > Regards > > > > Jon > > > >> -----Original Message----- > >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > >> Sent: 07 April 2020 18:42 > >> To: Achim Kraus; core@ietf.org > >> Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > >> Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > >> New BLOCK Option? > >> > >> Hi Achim, > >> > >> Please see inline. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Achim Kraus [mailto:achimkraus@gmx.net] > >>> Envoy=C3=A9 : mardi 7 avril 2020 18:50 > >>> =C3=80 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org > >>> Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > >>> Objet : Re: [core] Large asynchronous notifications under DDoS: = New > >>> BLOCK Option? > >>> > >>> Hi Med, > >>> > >>> I think, not all assumption and requirements are clear to = everyone. > >>> > >> > >> [Med] We are using CoAP for signaling DDoS attacks and for seeking = help > >> from a DDoS mitigator. The mitigation signal itself is compact as = we do > > have > >> a requirement that the signal channel survive under extreme DDoS > >> conditions. We do have a mechanism to maintain the signal alive, to > detect > >> when it is lost and then to recover asap. > >> > >> We are now designing an extension to the base signaling that allows = to > >> share knowledge of attacks for better coordination and efficient > > mitigation. > >> To that aim, we need to signal DDoS telemetry data between our DOTS > >> agents (CoAP endpoints). > >> > >>> I guess, your mission is to send a couple of "block" messages, but > >>> without getting requested for the next-blocks, because the node is > >>> under > >>> attack and already receiving too much. Therefore the SACK will be = used > >>> a > >>> little later as "cleanup"/"collect lefts". > >> > >> [Med] Yes. > >> > >>> > >>> My first idea about that was, that sending the "block-flush" just > >>> creates the next attack. But, if you sure, that this doesn't = happen, > >>> then such an approach may help in that special situation. > >> > >> [Med] Yes. > >> > >>> > >>> I'm not sure, if you assume, that in the most cases all blocks = will > >>> make > >>> it to the destination when sending them. That may also depend on = the > >>> assumed number of blocks. If it's not assumed, that all block will = be > >>> received, your payload should be encoded in a way, that you could > >>> decode > >>> the received blocks, even if some blocks are missing. > >> > >> [Med] This is will be nice to have. This might be managed at the > > application > >> (DOTS) level but there are some challenges as well (make sure that = the > >> crafted data will fit a single DTLS packet). > >> > >>> > >>> If that number is not too large, maybe a "blockwise with NSTART-X" > >>> will > >>> also do it. Especially if DTLS is used, it may be possible to = concat > >>> the > >>> "ACK/next blocks" into one package (with multiple records). AFAIK, > >>> that > >>> would require changes in implementations, which optimizes the > >>> deduplication base on a strict sequence of blocks, but the = difference > >>> should be not too large. > >>> > >>> best regards > >>> Achim > >>> > >>> > >>> Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > >>>> Hi all, > >>>> > >>>> We are using Observe to receive notifications during attack = events. > >>>> These notifications are set as NON messages for reasons specific = to > >>> DDoS > >>>> conditions. > >>>> > >>>> With DDoS telemetry information included (see > >>>> draft-ietf-dots-telemetry), a notification may not fit one single > >>>> message. The use of BLOCK2 is not convenient during attack times. = A > >>> full > >>>> description of the issue is described here: > >>>> > >>> > >> > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW > >> eP4 > >>> / > >>>> > >>>> We are considering some mechanisms to solve this issue. One of = them > >>> is > >>>> to define a new BLOCK option (similar to BLOCK2) that does not > >>> require > >>>> the observer to send a GET to receive the next fragment. The = server > >>> will > >>>> send all the fragments. The observer will follow a SACK-like > >>> 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 > >>>> > >>>> > >>>> _______________________________________________ > >>>> core mailing list > >>>> core@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/core > >>>> > >> > >> _______________________________________________ > >> Dots mailing list > >> Dots@ietf.org > >> https://www.ietf.org/mailman/listinfo/dots > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 7 13:27:00 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 3B9633A12A3; Tue, 7 Apr 2020 13:26:52 -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 (1024-bit key) header.d=gmx.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 xdiyqLMEhSb1; Tue, 7 Apr 2020 13:26:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 B76D23A10D8; Tue, 7 Apr 2020 13:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586291192; bh=foLXtyc5U0FmFQMbdhDKJXKZLzxum8wuCIbBBA32raY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=PHgQ4y3ugUHgwptbMRSuyoKKkGj6rFdufdP/tHyWT1IAYDyvPncAmk+mQqD8LSTQr PzSkmU8zMKfyLZqYDM3AC2vDjYN5PLqBmnzB/qamTdQvWwmPlDfFlxsAovhin2sC6S jtLGpMyPzZ1GhfCYfA//LB3wLbmkMMCq5gZdhE/M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MmULx-1ivcOP12Ez-00iPXV; Tue, 07 Apr 2020 22:26:32 +0200 To: Jon Shallow , mohamed.boucadair@orange.com, core@ietf.org, dots@ietf.org References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <01ad01d60d17$470b9a80$d522cf80$@jpshallow.com> From: Achim Kraus Message-ID: <0955fc85-8d5a-f1c4-b618-f692b27ad9d3@gmx.net> Date: Tue, 7 Apr 2020 22:26:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <01ad01d60d17$470b9a80$d522cf80$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:2LR+gFhIuGDPk3+BeJ/s3k6ORVCJWTz/XVqBbFceMC4Dhvvafey Vgd4w0sMbcvy2LaNCDjxcEYni1p6zzuHxONlQ+STPiuFX+TZZEJ+qFsqivHBlpXu9CQUF9n 91pye3EVdNsDKfSS0RrMmvuX/4+bHpCv/U7g82KhFVrGAYHi4zNp7iEnrLbeJKrpd7C9gXN dZttWQnAv3nVdYTcR6txg== X-UI-Out-Filterresults: notjunk:1;V03:K0:bujNJ5+2aWo=:hFeTR5zmW0kWg1zFQK/ov+ yxZQmS6lNaxQRwIct+UnfQnbIkD4psB0n9XeuvQxC7Xs+lvarryZ7039OCVYKkhBk3ErzPlbN 6oV++WpFvzqPKcTgNAfXsF9HkhJhoIM5iHh1cdPt6hcr7T7HDKSwDBYGMWXBPAQZD73zH2FVw C8UjXOV3br8ApO0nd0UssyfqO1l5Zw8sKakHMvrA+tSnZe/CnUChkgEC+bRjEuxAm6PylxmtJ wU1/O19GjhhxGSyeSp09+N+75EjM9tfYHK42DVXR0ivkq2RXEiBOSQ73ZEli09dQSjQGJaxFY hNAbD9cjc0O9goBdrPiENdJaibPxjJ64KBqadRL1yg2CEHy8ycSLSxASXINkYZz0pM5K/Ny1Y K47pMpqF5/91cla2MTvEeCPv+FbZLjwFvHgAcKlhHluwdzQXAzQcUQiIzY5FmVoP0NmOJu2w+ hbh7XWIJUptGwV0E2s0j8rC2ao/SHuEDUjUFltzxuwFZeocPOrAkmbSeHL1cS5lczm6VcOdJw 75Lyj3bnALYDXAjHvwGJ/3UReJzrrH0Eajl75DvEciMgKfss1wFcxFAcHYBbrM/dkT9d/62zA JF0chakMMbn1IQ1L8r6DcHH0Cz5Y7KbPprGhzBSfwVEgZvBbtiuXBE6PxwP8HllI8xh9q0kNP sh2ErgXpLL1R2rloA8if77HZPGh3CnpSsMfUEEv4ieB9HEcIDsmr1A6N1iXxUxhPtxwaVvbwb c9TC9LQVPc0Lo35I7FNKPgkCEVUapdzc/7K+uDu5yme8NEelUx7u+hz4/Z9GoxOQt8GPp/6YP m9CI7EUqeixJMUBjFG7+5dYbrZb80YpqlRriRHmUaO7RcF6/DQ0RLmHDsURdfE7pNKk8MVrIz o9zoPN6TfEKskAnz9hf7eHJI9OuhwkLRe6Q1B6EZoM9GvhmfNvXobtkJZ7dFpssE0QwfTK3wq CBNqHgSRkg5ZX1pSV59fcgylKCZ0vKfooYOTiSskoGCCq3sBBik1MLzoOm1tKzcWBJd9Y5Fwm FgABRt2svbZ35END2/lqXfaGBvXoFv1tQzLA6D2zvidvZTrCaTUF5f3ejoOKwLIGTcag9AzJc PtJ74AjmOWn3FNiRspxJJaK9vC4WjGq2aeA6hiwdFDzxkKoRUoEzlAX9qrjZDkS5qYmkDCYYl BxcRJnxZBJYRk2pHv1+sugBefNwOu3llRi/3jgEWFn2ZAGxZdg+BnEiqHJdPu7oVK9YgqKuZC IibOp29R8zly/ZIVX Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 20:26:57 -0000 Hi Jon, Jon> I don't quite follow why a proxy will not work unless you are referring to blockwise resources with gaps. Yes, the point is the blockwise with gaps. Jon> It may make for less changes, but I was expecting the NONBLOCK2 option to be handled within the application rather than at the CoAP layer. In the DOTS case, server enhanced Telemetry information sending has to be explicitly enabled by the client so existing implementations will not get broken. If it's not a modification of the coap-layer, which kind of messages are you plan to use? Multiple NON-responses (wouldn't that be notifies)? Or NON requests with "no-response"? best regards Achim Am 07.04.20 um 22:01 schrieb Jon Shallow: > Hi Achim, > > It is good to get this feedback. Please see inline Jon1> > > Regards > > Jon > >> -----Original Message----- >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus >> Sent: 07 April 2020 20:04 >> To: Jon Shallow; mohamed.boucadair@orange.com; core@ietf.org; >> dots@ietf.org >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: >> New BLOCK Option? >> >> Hi Jon, >> >> I'm still not sure, if such an approach would make sense: >> - if multiple blocks are required without gaps >> - the package loss is high >> =3D> that ends up in not receiving any "large payload" at all. > > Jon> The packet loss should be transitory in that if the DDoS Mitigation= is effective and reduces the rate of the DDoS Attack through the pipe nor= mal (certainly DOTS) service is resumed. DOTS needs to be able to continu= e with limiting working with high packet loss as "PUT new mitigation reque= st" are still likely to get through. > >> >> FMPOV, the first thing to ensure is, that the "large payload" gets spli= t >> into "application blocks", which could be processed even when other >> application blocks are missing. > > Jon> We are also trying to do this as well, but it is not that straightf= orward. >> >> I would also not assume, that a "in between proxies" will be able to >> process blockwise resources with gaps. > > Jon> In the DOTS case, we have the concept of DOTS gateways where the DO= TS CoAP server and DOTS CoAP client stacks are fully terminated making thi= ngs easier here. This is a good point though and needs to be worked throu= gh. > >> So I'm not sure, why >> observer/notify is used. If it should be used, (and a proxy will not >> work,) > > Jon> I don't quite follow why a proxy will not work unless you are refer= ring to blockwise resources with gaps. > >> then you may consider to "misuse" the notifies and send your >> "application blocks" just in multiple notifies (each application block >> in one notify, without droping "old" notifies, because they are not old >> :-) ). In my opinion that would require less changes to existing >> implementations than introduce a "blockwise without next". > > Jon> It may make for less changes, but I was expecting the NONBLOCK2 opt= ion to be handled within the application rather than at the CoAP layer. I= n the DOTS case, server enhanced Telemetry information sending has to be e= xplicitly enabled by the client so existing implementations will not get b= roken. > >> >> In the end, it would be interesting, if such a improvement really pays >> off. Using some nodes with standard blockwise and others with the new >> one should show the benefit. It would be great, if you then report your >> numbers. > > Jon> I will see what I can come up with here. A good suggestion. It ma= y take a while though as I have only partially got the DOTS telemetry draf= t extensions coded. > ~Jon > >> >> best regards >> Achim >> >> Am 07.04.20 um 19:56 schrieb Jon Shallow: >>> Hi Achim, >>> >>> To add to Med's inline comments, the use case that we are trying to so= lve >> is >>> as follows. >>> >>> We are trying to send telemetry information from a server to a unicast >>> client which has the potential to exceed the size of IP packet (possib= ly >>> multiple times too large). >>> >>> The environment that this telemetry information is going to be >> transmitted >>> in will be where Distributed Denial of Service (DDoS) attacks are taki= ng >>> place and so there is a high chance that network pipes will be running= at or >>> near capacity and hence there is likely to be high packet loss. It is >>> likely that the direction of the telemetry data is the same as that of= the >>> packet loss. >>> >>> This telemetry is an additional tool for passing information about how >>> mitigations of these DDoS attacks are being effective so that decision= s can >>> be taken as to how better to mitigate the DDoS situation. This is mak= ing >>> use of the DDoS Open Threat Signaling protocol (DOTS) described in >> RFC8612 >>> with other drafts for components of this protocol in the final stages = of >>> becoming RFCs ( https://tools.ietf.org/wg/dots/ ). >>> >>> While not desirable, it is acceptable if the client is unable to recei= ve the >>> telemetry data (out of band mechanisms such as phone calls can be used >> in >>> slow time if needed for tuning against attacks) but we would like to >>> maximize the possibility of the telemetry data getting through. >>> >>> Currently with other data and small amounts of telemetry, the GET >> response >>> or Observe data can safely be sent off from the server and the client = may >> or >>> may not get it as we are using NON-confirmable. PUT (which has small >>> amounts of data) and DELETE are also sent as NON-confirmable - and the >>> client handles things if there is not seen a 2.XX etc. response to the >>> PUT/DELETE. >>> >>> This issue is when the data is too large to fit into a single packet -= we >>> currently use the CoAP BLOCK2 option which works fine under normal >> traffic >>> conditions, but relies on the client synchronously requesting the next >> block >>> of data. We currently are doing this as NON-confirmable so a loss of = a >>> block of data causes the transfer to stall with the need to do garbage >>> collection at a later point in time ion the server. Using CONfirmable >>> causes everything to slow right down with the lossy network and preven= ts >> the >>> next CON transmission for a long time as NSTART is 1. >>> >>> The data is CBOR based on YANG with the YANG parameters two-way >> mapped into >>> integers to give as much CBOR data reduction as possible, so cannot sa= ve >> any >>> space there. It is theoretically possible to reduce the amount of tel= emetry >>> data by only asking for subsets of information as Med has referred to = in >>> this email trail. >>> >>> It is possible to solve the issue using IP fragmentation and let the c= lient >>> re-assemble everything, but this is not ideal in a lossy network and t= here >>> is no way to ask for a particular IP fragment to be re-transmitted. >>> >>> If there was a new CoAP option - let's call it NONBLOCK2, which the se= rver >>> uses to send the all the data packets without waiting for the GET requ= est >> of >>> the next block (only difference compared with BLOCK2). If the client = does >>> not see all the blocks after a timeout, it can then request the missin= g >>> blocks by using one or more of the NONBLOCK2 options in a new GET >> request - >>> or just wait until the next GET / Observe response. This may be a way= to >>> move forward if we cannot solve the issue in another way. >>> >>> Regards >>> >>> Jon >>> >>>> -----Original Message----- >>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>>> Sent: 07 April 2020 18:42 >>>> To: Achim Kraus; core@ietf.org >>>> Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >>>> Subject: Re: [Dots] [core] Large asynchronous notifications under DDo= S: >>>> New BLOCK Option? >>>> >>>> Hi Achim, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Achim Kraus [mailto:achimkraus@gmx.net] >>>>> Envoy=C3=A9 : mardi 7 avril 2020 18:50 >>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org >>>>> Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >>>>> Objet : Re: [core] Large asynchronous notifications under DDoS: New >>>>> BLOCK Option? >>>>> >>>>> Hi Med, >>>>> >>>>> I think, not all assumption and requirements are clear to everyone. >>>>> >>>> >>>> [Med] We are using CoAP for signaling DDoS attacks and for seeking he= lp >>>> from a DDoS mitigator. The mitigation signal itself is compact as we = do >>> have >>>> a requirement that the signal channel survive under extreme DDoS >>>> conditions. We do have a mechanism to maintain the signal alive, to >> detect >>>> when it is lost and then to recover asap. >>>> >>>> We are now designing an extension to the base signaling that allows t= o >>>> share knowledge of attacks for better coordination and efficient >>> mitigation. >>>> To that aim, we need to signal DDoS telemetry data between our DOTS >>>> agents (CoAP endpoints). >>>> >>>>> I guess, your mission is to send a couple of "block" messages, but >>>>> without getting requested for the next-blocks, because the node is >>>>> under >>>>> attack and already receiving too much. Therefore the SACK will be us= ed >>>>> a >>>>> little later as "cleanup"/"collect lefts". >>>> >>>> [Med] Yes. >>>> >>>>> >>>>> My first idea about that was, that sending the "block-flush" just >>>>> creates the next attack. But, if you sure, that this doesn't happen, >>>>> then such an approach may help in that special situation. >>>> >>>> [Med] Yes. >>>> >>>>> >>>>> I'm not sure, if you assume, that in the most cases all blocks will >>>>> make >>>>> it to the destination when sending them. That may also depend on the >>>>> assumed number of blocks. If it's not assumed, that all block will b= e >>>>> received, your payload should be encoded in a way, that you could >>>>> decode >>>>> the received blocks, even if some blocks are missing. >>>> >>>> [Med] This is will be nice to have. This might be managed at the >>> application >>>> (DOTS) level but there are some challenges as well (make sure that th= e >>>> crafted data will fit a single DTLS packet). >>>> >>>>> >>>>> If that number is not too large, maybe a "blockwise with NSTART-X" >>>>> will >>>>> also do it. Especially if DTLS is used, it may be possible to concat >>>>> the >>>>> "ACK/next blocks" into one package (with multiple records). AFAIK, >>>>> that >>>>> would require changes in implementations, which optimizes the >>>>> deduplication base on a strict sequence of blocks, but the differenc= e >>>>> should be not too large. >>>>> >>>>> best regards >>>>> Achim >>>>> >>>>> >>>>> Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: >>>>>> Hi all, >>>>>> >>>>>> We are using Observe to receive notifications during attack events. >>>>>> These notifications are set as NON messages for reasons specific to >>>>> DDoS >>>>>> conditions. >>>>>> >>>>>> With DDoS telemetry information included (see >>>>>> draft-ietf-dots-telemetry), a notification may not fit one single >>>>>> message. The use of BLOCK2 is not convenient during attack times. A >>>>> full >>>>>> description of the issue is described here: >>>>>> >>>>> >>>> >> https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW >>>> eP4 >>>>> / >>>>>> >>>>>> We are considering some mechanisms to solve this issue. One of them >>>>> is >>>>>> to define a new BLOCK option (similar to BLOCK2) that does not >>>>> require >>>>>> the observer to send a GET to receive the next fragment. The server >>>>> will >>>>>> send all the fragments. The observer will follow a SACK-like >>>>> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>> >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > From nobody Tue Apr 7 14:19: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 8A6E13A134C; Tue, 7 Apr 2020 14:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rQoX3QQ1bvE0; Tue, 7 Apr 2020 14:19:02 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614333A134A; Tue, 7 Apr 2020 14:19:00 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48xgJL5t8lzySC; Tue, 7 Apr 2020 23:18:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 7 Apr 2020 23:18:58 +0200 Cc: Jon Shallow , mohamed.boucadair@orange.com, core , dots@ietf.org X-Mao-Original-Outgoing-Id: 607987138.268279-c8b953ef6a0c78172142dc3c02ae1b1c Content-Transfer-Encoding: quoted-printable Message-Id: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> To: Achim Kraus X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 21:19:05 -0000 Hi Achim, On 2020-04-07, at 21:04, Achim Kraus wrote: >=20 > FMPOV, the first thing to ensure is, that the "large payload" gets = split > into "application blocks", which could be processed even when other > application blocks are missing. Indeed, =E2=80=9Capplication layer framing=E2=80=9D comes to mind here; = that is always a good idea if it cannot be ensured that all messages = make it or if it is good to be able to process messages while still = waiting for others. .oOo. I=E2=80=99m trying to understand the very specific network environment = that we are targeting here. Are we assuming packets are way more likely to make it from the server = to the client than the other way around? That indeed would call for additional capabilities that base CoAP does = not have. We also may not really care about congestion control much in a situation = of massive (attacker-induced) congestion (although that might be = misdiagnosed, so some care is still required); which would be another = reason to maybe deviate from base CoAP. I don=E2=80=99t have a design in mind at the moment. It would need to = cater for the fact that sending the other response messages for the = request would be on the initiative of the server. So observe (with non-confirmable responses) is maybe a good model = indeed; what=E2=80=99s missing is some way to ask for gaps. I just resubmitted a draft that we have been discussing for a while in = T2TRG: The Series Transfer Pattern (STP) https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html This has some discussion that may be relevant here, although it does not = address the specific DOTS problem. I think it would be great if = whatever we come up with to solve this problem would also be a step = forward on the larger class of applications needing the series transfer = pattern. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 15:28: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 ECEC43A003D; Tue, 7 Apr 2020 15:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 T6tYwyCzBWCS; Tue, 7 Apr 2020 15:28:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857943A0030; Tue, 7 Apr 2020 15:28:09 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48xhr63HHzzyT1; Wed, 8 Apr 2020 00:28:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> Date: Wed, 8 Apr 2020 00:28:05 +0200 X-Mao-Original-Outgoing-Id: 607991285.95842-e0f44b69f3e2bfa5dfa950f2c423a116 Content-Transfer-Encoding: quoted-printable Message-Id: References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> To: core , dots@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 22:28:13 -0000 On 2020-04-07, at 23:18, Carsten Bormann wrote: >=20 > The Series Transfer Pattern (STP) > https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html https://www.ietf.org/id/draft-bormann-t2trg-stp-03.html (forgot to process the figures.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 8 02:06:26 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 0FBCB3A0EB9; Wed, 8 Apr 2020 02:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZYaU1dOXqC-y; Wed, 8 Apr 2020 02:06:14 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539923A0EB8; Wed, 8 Apr 2020 02:06:12 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D859540147; Wed, 8 Apr 2020 11:06:10 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D01E914B; Wed, 8 Apr 2020 11:06:06 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 91815381; Wed, 8 Apr 2020 11:06:06 +0200 (CEST) Received: (nullmailer pid 2853630 invoked by uid 1000); Wed, 08 Apr 2020 09:04:36 -0000 Date: Wed, 8 Apr 2020 11:04:36 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "core@ietf.org" , "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Message-ID: <20200408090436.GC2844485@hephaistos.amsuess.com> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200407130944.GA2738832@hephaistos.amsuess.com> <787AE7BB302AE849A7480A190F8B93303149075C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149075C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 09:06:16 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, On Tue, Apr 07, 2020 at 03:51:14PM +0000, mohamed.boucadair@orange.com wrot= e: > I don't see where in the two drafts an observer can request a particular = missing fragment.=20 Observation combined with block-wise transfer generally has the observer request all the remaining blocks when an updates comes in, as illustrated in [1]. Those do not even necessarily need to be requested in sequence. If a mechanism gets added that allows the server to send additional blocks after a first request (and I'd appreciate that, maybe we can get that resurfaced in the upcoming meeting's AOB section), the client may miss some of them, but can still fall back to that original mechanism. Kind regards Christian [1]: https://tools.ietf.org/html/rfc7959#section-3.4 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6Nk6AACgkQOY0REtOk veHiWBAAmbZW/16cgSWLsDEKaIQeYDA9dnuoOLJQy/ushCTtHFNHU+bvWOKZ7wqy XSnTL7T7x/tR5AlZ/5bgrs3ZM2SoeAk1jdcrntLdeY+DB9EiyZ2e0T6x1wgm9UMU rgJab/Hoa2040t4OAn77Dtp4mtU39e9mscjARZjh/oXUhKjz39cFkmZQIU/zHraq RnnAXlUjqo8bPFbhcLHVsTFT4Efa8h4BPgNuCWyYfVy+/uZ9pjVPNI/V6XWnxptE RR/tl9dbZUpRScryjk6lEB7C/ZgpPdygCxgmFgh9XlG6dyitCAXnNr3mNV3Y8g1X zmmwql4Yu8WgACBn8su9SWplVaMKzNjQpRKqJ4/2IkfesQqRNwE6GEmrkOqvTwsY RmS8Aewwavd746JcqrgCYm/DJcbeno8PTCb6ZrQdP0GAkVXwfO3tQ6oREuIR5hEK 0dbrpxwxUgx43oOsABgZOCYfokQXQ3MaZLmzd5wzpzLYAeNsoSH9rjErtGPxHoiI gwjouRPNh3J8PxXCNju1G9xZ/JT9/BlLz17loi07TZ+2Ab72wDDr1+YQD1ZCkw3o zVvbcCOsGFfW6osOGRO/ZBDYYY9WKJrdqA5vrDEJ0vSi14m2TWTzLp1DbOtZ3sKI qK8qqOsk3nQrUvwFmC0Dm3qe4aawEtTzNt74iynlSP40mM9cz4A= =Mvla -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From nobody Wed Apr 8 02:56:29 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 96A223A0FE5; Wed, 8 Apr 2020 02:56:18 -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, 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 C67rlb0-Ugoo; Wed, 8 Apr 2020 02:56:17 -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 EF2EC3A0FE4; Wed, 8 Apr 2020 02:56:16 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48y0663tZNz5vdm; Wed, 8 Apr 2020 11:56:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586339774; bh=iHbYQjpslX5s7pGcTMA04lnQcW5heQhj96FyHxcUN4o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=o20XXuT1ChSeC3SS1oilAelf6cDJYFvsxRWVd2K5MNje2llffQZC12yvqNLl8sd9V VyUL0ikNizMXTLgn0695MnYWVQ+7UJLdHNSbOkPebOEkVvVe+4NKsUZg9RdTnp6SxQ iV2zPKhjtNtIykFrM6dIGfqXhONGsihG754LZpDIhuumVsWbbwQo1DfEfZNGBTgW8m Lr0MrR1aG6DXXByYcGsVj0rGerz5P687rlAIN941BqORQDF7JY6L01TrXTMM1XYO8y X3S0UcrRCDcfwwBdhHJ41TWzpuPUwhaX95uNBJB3C/E/El8y+eqHnO8qCz0DB4Odeh lvgvtIIT6tPsg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48y0662nVxz8sZj; Wed, 8 Apr 2020 11:56:14 +0200 (CEST) From: To: Carsten Bormann CC: Jon Shallow , core , "dots@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDYvwpy/bxUigK0iz1rVnLiHoRg== Date: Wed, 8 Apr 2020 09:56:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> In-Reply-To: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> 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] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 09:56:19 -0000 SGkgQ2Fyc3RlbiwNCg0KV2UgYXJlIGFsc28gY29uc2lkZXJpbmcgaG93IHRvIHNvbHZlIHRoZSBp c3N1ZSBhdCB0aGUgRE9UUyBsZXZlbC4gVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHdlIGFyZSBub3Qg YmxpbmRseSBvdmVycmlkaW5nIHBpZWNlcyBvZiBkYXRhIHRoYXQgYXJlIHJlY2VpdmVkIGluIGRp c3RpbmN0IHJlc3BvbnNlcy4gV2UgaGF2ZSBzb21lIGNoZWNrcyB0byB1cGRhdGUgYW4gYWN0aXZl IHJlY29yZC4gQnV0IGFzIG1lbnRpb25lZCBieSBKb24sIHRoZXJlIGFyZSBzb21lIGNoYWxsZW5n ZXMgYXMgd2VsbC4gDQoNCldpdGggcmVnYXJkcyB0byB0aGUgbmV0d29yayBlbnZpcm9ubWVudCwg dGhlIGRpcmVjdGlvbiBvZiB0aGUgYXR0YWNrIGlzIHRoZSBzYW1lIGFzIHRoZSBvbmUgZnJvbSBz ZXJ2ZXJzIHRvIGNsaWVudHMuIFRoYXTigJlzIHNhaWQsIHRlbGVtZXRyeSBkYXRhIGNhbiBiZSBl eGNoYW5nZWQgaW4gYm90aCBkaXJlY3Rpb25zOg0KDQoqIGZyb20gY2xpZW50IHRvIHNlcnZlcnM6 IHVzaW5nIGEgZGVkaWNhdGVkIHRlbGVtZXRyeSBtZXNzYWdlIG9yIGluIGFuIGVmZmljYWN5IHVw ZGF0ZSBzaGFyZWQgd2l0aCB0aGUgc2VydmVyIHdoZW4gYSBtaXRpZ2F0aW9uIGlzIGFjdGl2ZS4g VGhpcyBpcyBkb25lIHVzaW5nIFBVVCBtZXNzYWdlcy4NCiogZnJvbSBzZXJ2ZXJzIHRvIGNsaWVu dHM6IHRlbGVtZXRyeSBkYXRhIGNhbiBiZSBzZW50IGluIGRlZGljYXRlZCBub3RpZmljYXRpb24g bWVzc2FnZXMgb3IgYXMgcGFydCBvZiB0aGUgbWl0aWdhdGlvbiBzdGF0dXMgdXBkYXRlLiBCb3Ro IHJlbHkgdXBvbiBHRVQrT2JzZXJ2ZS4gSGF2aW5nIGEgbWVjaGFuaXNtIHRvIGFzayBmb3IgZ2Fw cyB3b3VsZCB0aHVzIGJlIGhlbHBmdWwuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6 aS5vcmddDQo+IEVudm95w6nCoDogbWFyZGkgNyBhdnJpbCAyMDIwIDIzOjE5DQo+IMOAwqA6IEFj aGltIEtyYXVzDQo+IENjwqA6IEpvbiBTaGFsbG93OyBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xO OyBjb3JlOyBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbY29yZV0gW0RvdHNdIExhcmdl IGFzeW5jaHJvbm91cyBub3RpZmljYXRpb25zIHVuZGVyIEREb1M6DQo+IE5ldyBCTE9DSyBPcHRp b24/DQo+IA0KPiBIaSBBY2hpbSwNCj4gDQo+IE9uIDIwMjAtMDQtMDcsIGF0IDIxOjA0LCBBY2hp bSBLcmF1cyA8YWNoaW1rcmF1c0BnbXgubmV0PiB3cm90ZToNCj4gPg0KPiA+IEZNUE9WLCB0aGUg Zmlyc3QgdGhpbmcgdG8gZW5zdXJlIGlzLCB0aGF0IHRoZSAibGFyZ2UgcGF5bG9hZCIgZ2V0cw0K PiBzcGxpdA0KPiA+IGludG8gImFwcGxpY2F0aW9uIGJsb2NrcyIsIHdoaWNoIGNvdWxkIGJlIHBy b2Nlc3NlZCBldmVuIHdoZW4gb3RoZXINCj4gPiBhcHBsaWNhdGlvbiBibG9ja3MgYXJlIG1pc3Np bmcuDQo+IA0KPiBJbmRlZWQsIOKAnGFwcGxpY2F0aW9uIGxheWVyIGZyYW1pbmfigJ0gY29tZXMg dG8gbWluZCBoZXJlOyB0aGF0IGlzIGFsd2F5cw0KPiBhIGdvb2QgaWRlYSBpZiBpdCBjYW5ub3Qg YmUgZW5zdXJlZCB0aGF0IGFsbCBtZXNzYWdlcyBtYWtlIGl0IG9yIGlmIGl0DQo+IGlzIGdvb2Qg dG8gYmUgYWJsZSB0byBwcm9jZXNzIG1lc3NhZ2VzIHdoaWxlIHN0aWxsIHdhaXRpbmcgZm9yIG90 aGVycy4NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgIC5vT28uDQo+IA0KPiBJ4oCZbSB0cnlp bmcgdG8gdW5kZXJzdGFuZCB0aGUgdmVyeSBzcGVjaWZpYyBuZXR3b3JrIGVudmlyb25tZW50IHRo YXQgd2UNCj4gYXJlIHRhcmdldGluZyBoZXJlLg0KPiBBcmUgd2UgYXNzdW1pbmcgcGFja2V0cyBh cmUgd2F5IG1vcmUgbGlrZWx5IHRvIG1ha2UgaXQgZnJvbSB0aGUgc2VydmVyDQo+IHRvIHRoZSBj bGllbnQgdGhhbiB0aGUgb3RoZXIgd2F5IGFyb3VuZD8NCj4gVGhhdCBpbmRlZWQgd291bGQgY2Fs bCBmb3IgYWRkaXRpb25hbCBjYXBhYmlsaXRpZXMgdGhhdCBiYXNlIENvQVAgZG9lcw0KPiBub3Qg aGF2ZS4NCj4gV2UgYWxzbyBtYXkgbm90IHJlYWxseSBjYXJlIGFib3V0IGNvbmdlc3Rpb24gY29u dHJvbCBtdWNoIGluIGENCj4gc2l0dWF0aW9uIG9mIG1hc3NpdmUgKGF0dGFja2VyLWluZHVjZWQp IGNvbmdlc3Rpb24gKGFsdGhvdWdoIHRoYXQNCj4gbWlnaHQgYmUgbWlzZGlhZ25vc2VkLCBzbyBz b21lIGNhcmUgaXMgc3RpbGwgcmVxdWlyZWQpOyB3aGljaCB3b3VsZCBiZQ0KPiBhbm90aGVyIHJl YXNvbiB0byBtYXliZSBkZXZpYXRlIGZyb20gYmFzZSBDb0FQLg0KPiANCj4gSSBkb27igJl0IGhh dmUgYSBkZXNpZ24gaW4gbWluZCBhdCB0aGUgbW9tZW50LiAgSXQgd291bGQgbmVlZCB0byBjYXRl cg0KPiBmb3IgdGhlIGZhY3QgdGhhdCBzZW5kaW5nIHRoZSBvdGhlciByZXNwb25zZSBtZXNzYWdl cyBmb3IgdGhlIHJlcXVlc3QNCj4gd291bGQgYmUgb24gdGhlIGluaXRpYXRpdmUgb2YgdGhlIHNl cnZlci4NCj4gU28gb2JzZXJ2ZSAod2l0aCBub24tY29uZmlybWFibGUgcmVzcG9uc2VzKSBpcyBt YXliZSBhIGdvb2QgbW9kZWwNCj4gaW5kZWVkOyB3aGF04oCZcyBtaXNzaW5nIGlzIHNvbWUgd2F5 IHRvIGFzayBmb3IgZ2Fwcy4NCj4gDQo+IEkganVzdCByZXN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQg d2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgZm9yIGEgd2hpbGUgaW4NCj4gVDJUUkc6DQo+IFRoZSBT ZXJpZXMgVHJhbnNmZXIgUGF0dGVybiAoU1RQKQ0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1ib3JtYW5uLXQydHJnLXN0cC0wMi5odG1sDQo+IA0KPiBUaGlzIGhhcyBzb21lIGRpc2N1 c3Npb24gdGhhdCBtYXkgYmUgcmVsZXZhbnQgaGVyZSwgYWx0aG91Z2ggaXQgZG9lcw0KPiBub3Qg YWRkcmVzcyB0aGUgc3BlY2lmaWMgRE9UUyBwcm9ibGVtLiAgSSB0aGluayBpdCB3b3VsZCBiZSBn cmVhdCBpZg0KPiB3aGF0ZXZlciB3ZSBjb21lIHVwIHdpdGggdG8gc29sdmUgdGhpcyBwcm9ibGVt IHdvdWxkIGFsc28gYmUgYSBzdGVwDQo+IGZvcndhcmQgb24gdGhlIGxhcmdlciBjbGFzcyBvZiBh cHBsaWNhdGlvbnMgbmVlZGluZyB0aGUgc2VyaWVzDQo+IHRyYW5zZmVyIHBhdHRlcm4uDQo+IA0K PiBHcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Wed Apr 8 03:41: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 2F0603A1003; Wed, 8 Apr 2020 03:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WgNf07dIqBSY; Wed, 8 Apr 2020 03:41:09 -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 9B0413A1232; Wed, 8 Apr 2020 03:41:08 -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 1jM88k-0007Cq-O9; Wed, 08 Apr 2020 11:41:02 +0100 From: "Jon Shallow" To: , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 8 Apr 2020 11:41:08 +0100 Message-ID: <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXai+yvJw Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 10:41:11 -0000 Hi All, Thanks for all your input so far. It has helped my thinking, but I = still do not have a clear answer yet as how to best do this for the DOTS = specific situation as well as more general use cases. Below is a more graphical way of trying to describe what is happening = and how it may be possible to overcome some of the limitations of using = BLOCK2 in a lossy traffic environment (caused by DDoS attacks). Regards Jon Primary packet loss is from Server to Client [Server is DDoS mitigating out in Internet, Client is on premise, DDoS = flood against client] GET followed by Observe response - all working - as we would do it = today. CLIENT SERVER | | +--------->| GET /path Token 0xf0 Observe 0 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 0/1/1024 | | +--------->| GET /path Token 0xf0 Block2 1/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 1/1/1024 | | +--------->| GET /path Token 0xf0 Block2 2/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 2/1/1024 | | +--------->| GET /path Token 0xf0 Block2 3/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 3/0/1024 Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1235 Block2 0/1/1024 | | +--------->| GET /path Token 0xf1 Block2 1/0/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 1/1/1024 | | +--------->| GET /path Token 0xf1 Block2 2/0/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 2/1/1024 | | +--------->| GET /path Token 0xf1 Block2 3/0/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 3/0/1024 Confirmable ACK responses not displayed, nor Etag, Size2 or Maxage. Now with some packet loss. Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1236 Block2 0/1/1024 | | +--------->| GET /path Token 0xf2 Block2 1/1/1024 | | | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 1/1/1024 | | Timeout Retry if Confirmable +--------->| GET /path Token 0xf2 Block2 1/1/1024 | | | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 1/1/1024 | | Retries continue - eventually timing out and possibly killing CoAP = session. Communications can be locked out for 90 seconds as CoAP NSTART is 1. [DOTS uses NON-Confirmable for protocol reliability, not traffic = reliability] If not using Confirmable, then the Client needs to time out at the = application layer and retry, but can only go forward 1 block at a time = (does not have to be in sequential order). Server may need to garbage collect on resource with Etag. What may help the situation (but client can decide when current = Etag/Maxage is no longer valid and stop continue requesting, and server = may still need to garbage collect) New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on = client doing GET to get the next block synchronously. CLIENT SERVER | | +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 = 0/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 0/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 1/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 2/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 3/0/1024 Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 0/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 1/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 2/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 3/0/1024 Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 0/1/1024 | | | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 1/1/1024 | | | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 2/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 3/0/1024 Client realises blocks are missing and asks for the missing ones in one = go +--------->| GET /path Token 0xf1 NonBlock2 1/0/1024 = NonBlock2 2/0/1024 | | | X<-----+ 2.05 Token 0xf1 Observe 1236 NonBlock2 1/1/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1236 NonBlock2 2/1/1024 Get final missing block +--------->| GET /path Token 0xf2 NonBlock2 1/0/1024 | | |<---------+ 2.05 Token 0xf2 Observe 1236 NonBlock2 1/1/1024 Obviously the 3 second minimum for RTT calculations needs to be = maintained so that the Attack situation is not made worse. However, I = think it acceptable that all the NonBlock2s for a particular data set = are all sent as a stream. > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 08 April 2020 10:56 > To: Carsten Bormann > Cc: Jon Shallow; dots@ietf.org; core > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Carsten, >=20 > We are also considering how to solve the issue at the DOTS level. The = good > news is that we are not blindly overriding pieces of data that are = received in > distinct responses. We have some checks to update an active record. = But as > mentioned by Jon, there are some challenges as well. >=20 > With regards to the network environment, the direction of the attack = is the > same as the one from servers to clients. That=E2=80=99s said, = telemetry data can be > exchanged in both directions: >=20 > * from client to servers: using a dedicated telemetry message or in an > efficacy update shared with the server when a mitigation is active. = This is > done using PUT messages. > * from servers to clients: telemetry data can be sent in dedicated > notification messages or as part of the mitigation status update. Both = rely > upon GET+Observe. Having a mechanism to ask for gaps would thus be > helpful. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Carsten Bormann [mailto:cabo@tzi.org] > > Envoy=C3=A9 : mardi 7 avril 2020 23:19 > > =C3=80 : Achim Kraus > > Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; core; dots@ietf.org > > Objet : Re: [core] [Dots] Large asynchronous notifications under = DDoS: > > New BLOCK Option? > > > > Hi Achim, > > > > On 2020-04-07, at 21:04, Achim Kraus wrote: > > > > > > FMPOV, the first thing to ensure is, that the "large payload" gets > > split > > > into "application blocks", which could be processed even when = other > > > application blocks are missing. > > > > Indeed, =E2=80=9Capplication layer framing=E2=80=9D comes to mind = here; that is always > > a good idea if it cannot be ensured that all messages make it or if = it > > is good to be able to process messages while still waiting for = others. > > > > .oOo. > > > > I=E2=80=99m trying to understand the very specific network = environment that we > > are targeting here. > > Are we assuming packets are way more likely to make it from the = server > > to the client than the other way around? > > That indeed would call for additional capabilities that base CoAP = does > > not have. > > We also may not really care about congestion control much in a > > situation of massive (attacker-induced) congestion (although that > > might be misdiagnosed, so some care is still required); which would = be > > another reason to maybe deviate from base CoAP. > > > > I don=E2=80=99t have a design in mind at the moment. It would need = to cater > > for the fact that sending the other response messages for the = request > > would be on the initiative of the server. > > So observe (with non-confirmable responses) is maybe a good model > > indeed; what=E2=80=99s missing is some way to ask for gaps. > > > > I just resubmitted a draft that we have been discussing for a while = in > > T2TRG: > > The Series Transfer Pattern (STP) > > https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html > > > > This has some discussion that may be relevant here, although it does > > not address the specific DOTS problem. I think it would be great if > > whatever we come up with to solve this problem would also be a step > > forward on the larger class of applications needing the series > > transfer pattern. > > > > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 8 09:00:43 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 73CE03A0408; Wed, 8 Apr 2020 09:00:35 -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 (1024-bit key) header.d=gmx.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 D-Ykr7pzTXWX; Wed, 8 Apr 2020 09:00:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 5BA643A0C9C; Wed, 8 Apr 2020 09:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586361609; bh=zE+o/qm4iUUWhAnRA4fda2/H6OwZetAuWbJFlxAmQr8=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=gbt6q79ZIhojJ/LulXVTnEx5ievnjZIJzvNPm52mEH/FSl4TUizhxsA1pWyuW795/ tFD+3j+1vQi1td3G18d+1a4kKl36NacYobMShDckbwx0RqYx1/MmDpmOPWRrH2FNxK t8Zxre4KzYkF8/ktP+xDsxDBlXH/K6L5a29rMvXQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtwZ4-1j16vt22aS-00uJNJ; Wed, 08 Apr 2020 18:00:09 +0200 To: Jon Shallow , mohamed.boucadair@orange.com, cabo@tzi.org, dots@ietf.org, core@ietf.org References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> From: Achim Kraus Message-ID: <1cdc0e70-7e72-ef52-66e7-1d2056367fbf@gmx.net> Date: Wed, 8 Apr 2020 18:00:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+npY5J6KcNjWBB0go7dq/iEVFgg7nflttNGT3xIrlMg91glVZq3 07oOo2owerr0PqahBkl98QZ9phmd+JWrlm7dB8rx2Kyke+12cPYt9QnTb6wjiHfEjpmBDLJ S0yf7twi+q65tnVs+JalItAcfX7WD7t+hd3Ve1sHtcU9F5fKFJ4GRj3WCitPL/U0AevOWHs xcMzFdROakiLNAdCfH36g== X-UI-Out-Filterresults: notjunk:1;V03:K0:k8jJtTPAgoY=:+3+QO/R2l9EreViLM2PQJ8 v86g59jGHSowshDBdNwz1nUn1vL7lCsjmpTXq/ZD1kDpPHelOczAwEEpymeCEdI5OIzFnmDU9 /vYY2FphkZBTMsxAtOTCK8pVRmbt1MtrZc706dwSEGK9VX30Bb6jZq2QeEfZ67KCRtP1Lxbhq sLBjiXBKZVoLwK2aaf5RFv79RDn85VLqRmDNWbRqyzrLJNBI7dHMY8ZID1qYfmiu80eTuQHGH Kv30g9k8QeT1TBCxihPLmNuFO0ga9jZANtb0uEE0Ps3cGAltQYmwwJgWxeuAX9+2AphCWcbAZ ZcHgmPYgOP1B4dT0Hn6bfG0aG98HTDjNgXg8jVQvsmGK/NuIztSNnJSG9XHKEU+GelJIl/6vo iiWk7RQM5GLRAARamydLEw8xdjzB0XqAsqfN94mWLZBXQ7566pISXzEq3FLGFWBvpTjtTCOTj wvut7b62+d0CvhB5m/Zj+5ysD0KvqCIPEFkU6xLPuQnIzus0VfjPNECtxliD60/ZDlpu6Csnr 7jFt2mhgU3U/IChJPb0DMr15Y77BNnupZYwI6yZF0098kn5ELpBIds6QoVip3ogzD0dlBR/GI 4ohnlcVyouCzYELfuF0SbO4OZF2dfa1RJ4ZeuMY7qvEHAZzcjPRzS1uqv6Tpp+U37h1bLAfsa ikCuOktubVGrRSPA3kYiBTQvogdezA23C2FnSwNn6E4IFWMHMa8jznx5OeX6ug8rbwXmFoi6a qRtolavpF0wzaJYzldpg/CmqXoJ8s/3XPQMU1t9572szL59pdCCMIY0/nKF+4tPcrxrUyNy5F 5whwc0MchWIeg2hpo7zrnTLpb55YRgzClNy3RIIhwTQ+fPqxP+Rv2DnuHkeOCi9rJK+IAQ+4x QaZY0VmaiqKaHtOM4rOXkIOBx5OXMd4agaHkUAQtgyljFUPS/13Wf56a6lo5vSueCjrPpSVVL zRezrR6r2qGkAEZRovw3aID0eccsj0TQpGf0Drp7YkAd8/F+wkXmpxvuwMSdXBA0aMrbq2ebm GGtvhLNmjqvKIu6sEU7ouGoJWUOsmsKsW7hevGKDK2o2iwPw+PEZPr/ZAcJmTpvVFri+4ZJLM VjR8IpEgoNpVRajn/WrvHMxKrryU7GQMxhlweLh2sXxqFevrXHHeEITuNbcImRO01Fg8HBv5/ jnraVE9g3E2X4JjyBn642IQQ1Ht0btNk8DlWxj1HRxepQ9Tv0jDD1z6oHr2jylNpZkTKLd0Fd lkRz0wqd78Epsp/U9 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 16:00:36 -0000 Hi Jon, a "clear" answer will be hard to give, without actual experience of such special communication situations. FMPOV it would require some experiments under your assumed conditions to find answers. From your diagrams, I would conclude: - best, if the transfer works without sending messages back - to fill gaps, sending messages will be acceptable - both together, should then provide a "good enough" solution. Yes, experiments may show, that it works "good enough", or withdraw it (because the drops are too high). To some details of your sequences. Observe/Notify is defined in https://tools.ietf.org/html/rfc7959#section-3.4 - the follow up / next block transfers usually don't contain the observe option, only the "head". - the follow up / next block transfer don't need to share the token with the head, they use the tokens defined by each requests. In your scenario, there will be no "next block" request, and so you reuse the observer "token". There maybe implementations, which fail receiving follow up blocks, with observe options and the token of the observer request. Therefore your approach would require at least a implementation according that special interpretation, but will not work with all "RFC 7252-7641-7959" compliant implementations, because for me it adds special conventions. best regards Achim Am 08.04.20 um 12:41 schrieb Jon Shallow: > Hi All, > > Thanks for all your input so far. It has helped my thinking, but I stil= l do not have a clear answer yet as how to best do this for the DOTS speci= fic situation as well as more general use cases. > > Below is a more graphical way of trying to describe what is happening an= d how it may be possible to overcome some of the limitations of using BLOC= K2 in a lossy traffic environment (caused by DDoS attacks). > > Regards > > Jon > > Primary packet loss is from Server to Client > [Server is DDoS mitigating out in Internet, Client is on premise, DDoS f= lood against client] > > GET followed by Observe response - all working - as we would do it today= . > > CLIENT SERVER > | | > +--------->| GET /path Token 0xf0 Observe 0 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 0/1/1024 > | | > +--------->| GET /path Token 0xf0 Block2 1/0/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 1/1/1024 > | | > +--------->| GET /path Token 0xf0 Block2 2/0/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 2/1/1024 > | | > +--------->| GET /path Token 0xf0 Block2 3/0/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 3/0/1024 > Observe triggered > |<---------+ 2.05 Token 0xf0 Observe 1235 Block2 0/1/1024 > | | > +--------->| GET /path Token 0xf1 Block2 1/0/1024 > | | > |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 1/1/1024 > | | > +--------->| GET /path Token 0xf1 Block2 2/0/1024 > | | > |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 2/1/1024 > | | > +--------->| GET /path Token 0xf1 Block2 3/0/1024 > | | > |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 3/0/1024 > > Confirmable ACK responses not displayed, nor Etag, Size2 or Maxage. > > Now with some packet loss. > Observe triggered > |<---------+ 2.05 Token 0xf0 Observe 1236 Block2 0/1/1024 > | | > +--------->| GET /path Token 0xf2 Block2 1/1/1024 > | | > | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 1/1/1024 > | | > Timeout > Retry if Confirmable > +--------->| GET /path Token 0xf2 Block2 1/1/1024 > | | > | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 1/1/1024 > | | > Retries continue - eventually timing out and possibly killing CoAP sessi= on. > > Communications can be locked out for 90 seconds as CoAP NSTART is 1. > > [DOTS uses NON-Confirmable for protocol reliability, not traffic reliabi= lity] > > If not using Confirmable, then the Client needs to time out at the appli= cation layer and retry, but can only go forward 1 block at a time (does no= t have to be in sequential order). > Server may need to garbage collect on resource with Etag. > > What may help the situation (but client can decide when current Etag/Max= age is no longer valid and stop continue requesting, and server may still = need to garbage collect) > > New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on cli= ent doing GET to get the next block synchronously. > > > CLIENT SERVER > | | > +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 0/0/10= 24 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 0/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 1/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 2/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 3/0/1024 > Observe triggered > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 0/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 1/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 2/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 3/0/1024 > Observe triggered > |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 0/1/1024 > | | > | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 1/1/1024 > | | > | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 2/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 3/0/1024 > Client realises blocks are missing and asks for the missing ones in one = go > +--------->| GET /path Token 0xf1 NonBlock2 1/0/1024 NonBloc= k2 2/0/1024 > | | > | X<-----+ 2.05 Token 0xf1 Observe 1236 NonBlock2 1/1/1024 > | | > |<---------+ 2.05 Token 0xf1 Observe 1236 NonBlock2 2/1/1024 > Get final missing block > +--------->| GET /path Token 0xf2 NonBlock2 1/0/1024 > | | > |<---------+ 2.05 Token 0xf2 Observe 1236 NonBlock2 1/1/1024 > > Obviously the 3 second minimum for RTT calculations needs to be maintain= ed so that the Attack situation is not made worse. However, I think it ac= ceptable that all the NonBlock2s for a particular data set are all sent as= a stream. > > > >> -----Original Message----- >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucada= ir@orange.com >> Sent: 08 April 2020 10:56 >> To: Carsten Bormann >> Cc: Jon Shallow; dots@ietf.org; core >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: >> New BLOCK Option? >> >> Hi Carsten, >> >> We are also considering how to solve the issue at the DOTS level. The g= ood >> news is that we are not blindly overriding pieces of data that are rece= ived in >> distinct responses. We have some checks to update an active record. But= as >> mentioned by Jon, there are some challenges as well. >> >> With regards to the network environment, the direction of the attack is= the >> same as the one from servers to clients. That=E2=80=99s said, telemetry= data can be >> exchanged in both directions: >> >> * from client to servers: using a dedicated telemetry message or in an >> efficacy update shared with the server when a mitigation is active. Thi= s is >> done using PUT messages. >> * from servers to clients: telemetry data can be sent in dedicated >> notification messages or as part of the mitigation status update. Both = rely >> upon GET+Observe. Having a mechanism to ask for gaps would thus be >> helpful. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Carsten Bormann [mailto:cabo@tzi.org] >>> Envoy=C3=A9 : mardi 7 avril 2020 23:19 >>> =C3=80 : Achim Kraus >>> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; core; dots@ietf.org >>> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS: >>> New BLOCK Option? >>> >>> Hi Achim, >>> >>> On 2020-04-07, at 21:04, Achim Kraus wrote: >>>> >>>> FMPOV, the first thing to ensure is, that the "large payload" gets >>> split >>>> into "application blocks", which could be processed even when other >>>> application blocks are missing. >>> >>> Indeed, =E2=80=9Capplication layer framing=E2=80=9D comes to mind here= ; that is always >>> a good idea if it cannot be ensured that all messages make it or if it >>> is good to be able to process messages while still waiting for others. >>> >>> .oOo. >>> >>> I=E2=80=99m trying to understand the very specific network environment= that we >>> are targeting here. >>> Are we assuming packets are way more likely to make it from the server >>> to the client than the other way around? >>> That indeed would call for additional capabilities that base CoAP does >>> not have. >>> We also may not really care about congestion control much in a >>> situation of massive (attacker-induced) congestion (although that >>> might be misdiagnosed, so some care is still required); which would be >>> another reason to maybe deviate from base CoAP. >>> >>> I don=E2=80=99t have a design in mind at the moment. It would need to= cater >>> for the fact that sending the other response messages for the request >>> would be on the initiative of the server. >>> So observe (with non-confirmable responses) is maybe a good model >>> indeed; what=E2=80=99s missing is some way to ask for gaps. >>> >>> I just resubmitted a draft that we have been discussing for a while in >>> T2TRG: >>> The Series Transfer Pattern (STP) >>> https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html >>> >>> This has some discussion that may be relevant here, although it does >>> not address the specific DOTS problem. I think it would be great if >>> whatever we come up with to solve this problem would also be a step >>> forward on the larger class of applications needing the series >>> transfer pattern. >>> >>> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Wed Apr 8 11:55:59 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 601CE3A159A; Wed, 8 Apr 2020 11:55:57 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 ruaTMxiHblU4; Wed, 8 Apr 2020 11:55:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 CC5E73A1591; Wed, 8 Apr 2020 11:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586372142; bh=+TzULiD74WI8wkxBqsYv0FmnN2kwxxrujy32RSlBzPY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=AbpoYRzjuFhHgw7NyhMqFI8OtE/E46hSVGtsm97A61ii9G4NSBQlDIMDb3F8VZeCE EK8++KM4SDW97hqILoucyG7lIpg0JNg+jvb78iY0ReIiYjaH/5dtalBv+g6wfxhIXQ 0n0eTesGansDi8V1tTpVK27BA4pRHHnfNvfgkp8U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M8QS2-1jQdaA1vPc-004X5Q; Wed, 08 Apr 2020 20:55:42 +0200 To: Jon Shallow , mohamed.boucadair@orange.com, cabo@tzi.org, dots@ietf.org, core@ietf.org References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> From: Achim Kraus Message-ID: Date: Wed, 8 Apr 2020 20:55:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:4k/xm6lt2zUB7W70blU/VMByqCsYPeYkm0oy2+Oha9FafG/x2JT /du1fhh1qMwUorqqHSgmeQp9kgsqYLs3b9wrjnmTivgvvksD1JG4q2eJQo3H+A+BPNSdQSj Z9+9QTq3v4AC+9OjnW3S67F0rR/5tlTL4Ly0g2mQIzW0eHNvWdwbqMgHpAGYxnGiHlBAqYZ PVXCk3VN15QOKuLOb/LBg== X-UI-Out-Filterresults: notjunk:1;V03:K0:4W4smXEaV7k=:2BF8nafOVKttV+BikgPx6w fyRVksXL0eEypllR7aZh7OeAX3Hd63dt3l0WDoo0GI8IdVYOeJwof2PzRNpoYuCa5kWx0yxf6 kePtG8dTcVeoZjIwULFFBHfm6apbch1d2+wS7FzyDIx7u+cwd6ffO7mL4qJZglIIaXaC0za4h 81V7jhiEMpzadbQPWpB51Ht2ux2W85RJ31NcJhOcsog6IXAI442VL3JlKgojRqvL8AVjY8vk0 5TnV/4u53fiZSbWvk79Pw+BhAjiWB4F9obonGSRUi20Y+fmkSK3IugVkDiObR/+v7VR9INKIL lDrl0OhXwOPp4FlSsDDbF/TaxSW3dAC61kR22wkaekFL4TkWifi9RNnUID/opQka1LwDqQ3Je 54TKYNGCrBxVz/Z6IgQoCXpMphsC/ZXW9I3tpH3hhIzubPyLnQpi8RhysVjt+j9tblFMlahkd dJfeGT2JSKPAYCvNk829LTaogsc+C/YvItC1ygjAOAD7mzL5ok2cb8c0E5JBInBsv4NecviNU wNoLcR1GeOembuhux/VaIotZjlDjax5+CVOuBBzo6as6IsqyfAy4AL7/2vrQ661YazW1z4BXa 3o8rrAQM3DHSuKsbQc/2PkUTuPBHqqhJQif4+IUTEOahZ2Tk/KGMnRzVnwf5fe7UpeNebJc6c IJFZzB3Hl7hwu+KNinLsAXZVD626QopDFdvgIlvWEDiJwcCBi01WNF4GFbAzi2vGvozEvhFAa mN0Vyv0vvpKYyVXBaaC9jJSYelb+69Id30ImgRH66jjUijJllUY2kRdQdIE2IdrLHwOW1Papj IIwscO7fS2WgX0boa1HlvBgmPQ+mG3HpC3JJzTZHn3u1KbTZvu9i6SSxsBrdG73o3MDQKlXaZ 9H3aU7K0ltsXIho7L+5FeF35SuLAU7E/IWKmd5aL+d+ghMKQ1NV5Ou+zDbw7VpbC06IYkWNTO 1URTEdRIWIpDh2BXouau8KdobTUVzNgBN8PMGZueL2T1w8L5gGsU2iL+B/sv0aUHuC4gNsFdI OF2Le+c4ySpXCWsacslyIzdfoyM3Ojx5zWkn2YMYVt1SIYc0GjHJRKfGUe8+U254WgEAKYTrx BkXaP3tLr7YiQPiYx0yIxz0RiJClX7W9lrFPvyiclEcw3sZC1pnaLU49vOShTCLJ/1BALge4i vOFHJrNus54z5LHGF0gIqm5FUch2ULHaNi+ulXwu7DqBvOv+RzKlJm6eaPwcwHDSoulAHJiEs O6wS3yLX1XLpG6T1C Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 18:55:57 -0000 Hi Jon, let me try to demonstrate, how =E2=80=9Capplication layer framing=E2=80=9D= could look like: > New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on cli= ent doing GET to get the next block synchronously. > > > CLIENT SERVER > | | > +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 0/0/10= 24 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 0/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 1/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 2/1/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 3/0/1024 Do these messages in the application layer -> encode the messages =3D> put the encoded message as payload for ordinary notifies: CLIENT SERVER | | +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 0/0/10= 24 | | |<---------+ 2.05 Token 0xf0 Observe 1234 { 2.05 Token 0xf0 Observe abc NonBlock2 0/1/1024 } | | |<---------+ 2.05 Token 0xf0 Observe 1235 { 2.05 Token 0xf0 Observe abc NonBlock2 1/1/1024 } | | |<---------+ 2.05 Token 0xf0 Observe 1236 { 2.05 Token 0xf0 Observe abc NonBlock2 2/1/1024 } | | |<---------+ 2.05 Token 0xf0 Observe 1237 { 2.05 Token 0xf0 Observe abc NonBlock2 3/0/1024 } The outer notifies will be processed as usual, the application block logic is yours. Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1238 { 2.05 Token 0xf0 Observe abd NonBlock2 0/1/1024 } | | |<---------+ 2.05 Token 0xf0 Observe 1239 { 2.05 Token 0xf0 Observe abd NonBlock2 1/1/1024 } | | |<---------+ 2.05 Token 0xf0 Observe 1240 { 2.05 Token 0xf0 Observe abd NonBlock2 2/1/1024 } | | |<---------+ 2.05 Token 0xf0 Observe 1241 { 2.05 Token 0xf0 Observe abd NonBlock2 3/0/1024 } Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1238 { 2.05 Token 0xf0 Observe abd NonBlock2 0/1/1024 } | | | X<------+ 2.05 Token 0xf0 Observe 1239 { 2.05 Token 0xf0 Observe abd NonBlock2 1/1/1024 } | | | X<------+ 2.05 Token 0xf0 Observe 1240 { 2.05 Token 0xf0 Observe abd NonBlock2 2/1/1024 } | | |<---------+ 2.05 Token 0xf0 Observe 1241 { 2.05 Token 0xf0 Observe abd NonBlock2 3/0/1024 } Client realises blocks are missing and asks for the missing ones in one go +--------->| GET /path/ctrl Token 0xf1 { NonBlock2 1/0/1024 NonBlock2 2/0/1024 } | | | X<------+ 2.05 Token 0xf0 Observe 1242 { 2.05 Token 0xf0 Observe abd NonBlock2 1/1/1024 } | | |<...------+ 2.05 Token 0xf0 Observe 1243 { 2.05 Token 0xf0 Observe abd NonBlock2 2/1/1024 } Get final missing block +--------->| GET /path/ctrl Token 0xf2 { / NonBlock2 1/0/1024 } | | |<...------+ 2.05 Token 0xf0 Observe 1244 { 2.05 Token 0xf0 Observe abd NonBlock2 1/1/1024 } That should be not considered as "precise description of the application layer framing". It should just give a first impression, how coap standards could be used, and the specific stuff could be move to the application layer (reusing coap again). best regards Achim From nobody Wed Apr 8 12:25:34 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 1266B3A0C73; Wed, 8 Apr 2020 12:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ytJWUFKROziv; Wed, 8 Apr 2020 12:25:30 -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 6703D3A1615; Wed, 8 Apr 2020 12:25:29 -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 1jMGK8-0007To-5f; Wed, 08 Apr 2020 20:25:20 +0100 From: "Jon Shallow" To: "'Achim Kraus'" , , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <1cdc0e70-7e72-ef52-66e7-1d2056367fbf@gmx.net> In-Reply-To: <1cdc0e70-7e72-ef52-66e7-1d2056367fbf@gmx.net> Date: Wed, 8 Apr 2020 20:25:25 +0100 Message-ID: <02ae01d60ddb$74255190$5c6ff4b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXQLOrs3hAZCEAcyonF/o4A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 19:25:33 -0000 Hi Achim Thanks for this good feedback. Please see inline Jon> [I have just seen you sent an update which I will look at shortly] Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus > Sent: 08 April 2020 17:00 > To: Jon Shallow; mohamed.boucadair@orange.com; cabo@tzi.org; > dots@ietf.org; core@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Jon, >=20 > a "clear" answer will be hard to give, without actual experience of = such > special communication situations. FMPOV it would require some > experiments under your assumed conditions to find answers. >=20 > From your diagrams, I would conclude: > - best, if the transfer works without sending messages back > - to fill gaps, sending messages will be acceptable > - both together, should then provide a "good enough" solution. > Yes, experiments may show, that it works "good enough", or withdraw it > (because the drops are too high). Jon> Yes >=20 > To some details of your sequences. > Observe/Notify is defined in > https://tools.ietf.org/html/rfc7959#section-3.4 >=20 > - the follow up / next block transfers usually don't contain the = observe > option, only the "head". Jon> My mistake - only head should have the observe option. > - the follow up / next block transfer don't need to share the token = with > the head, they use the tokens defined by each requests. Jon> Fair enough. I was just using the 0xfc in Figure 13. >=20 > In your scenario, there will be no "next block" request, and so you > reuse the observer "token". There maybe implementations, which fail > receiving follow up blocks, with observe options and the token of the > observer request. Jon> Is this still true if Observe option is only in the head? I would = be using Etag. The head observe triggered block is the same as with = BLOCK2. Jon> The GET for the missing responses would have Etag so we can be sure = we are asking for the right thing. Jon> The initial GET that sets up the observe subscription deliberately = uses NonBlock2 so only client and servers that support nonBLock2 will = use it. >=20 > Therefore your approach would require at least a implementation > according that special interpretation, but will not work with all "RFC > 7252-7641-7959" compliant implementations, because for me it adds > special conventions. Jon> Removing the confusion about Observe option, I am struggling to = think of other reasons why it may not work - but I am on a rapid = learning curve here. ~Jon >=20 > best regards > Achim >=20 > Am 08.04.20 um 12:41 schrieb Jon Shallow: > > Hi All, > > > > Thanks for all your input so far. It has helped my thinking, but I = still do not > have a clear answer yet as how to best do this for the DOTS specific = situation > as well as more general use cases. > > > > Below is a more graphical way of trying to describe what is = happening and > how it may be possible to overcome some of the limitations of using > BLOCK2 in a lossy traffic environment (caused by DDoS attacks). > > > > Regards > > > > Jon > > > > Primary packet loss is from Server to Client > > [Server is DDoS mitigating out in Internet, Client is on premise, = DDoS flood > against client] > > > > GET followed by Observe response - all working - as we would do it = today. > > > > CLIENT SERVER > > | | > > +--------->| GET /path Token 0xf0 Observe 0 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 = 0/1/1024 > > | | > > +--------->| GET /path Token 0xf0 Block2 1/0/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 = 1/1/1024 > > | | > > +--------->| GET /path Token 0xf0 Block2 2/0/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 = 2/1/1024 > > | | > > +--------->| GET /path Token 0xf0 Block2 3/0/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 = 3/0/1024 > > Observe triggered > > |<---------+ 2.05 Token 0xf0 Observe 1235 Block2 = 0/1/1024 > > | | > > +--------->| GET /path Token 0xf1 Block2 1/0/1024 > > | | > > |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 = 1/1/1024 > > | | > > +--------->| GET /path Token 0xf1 Block2 2/0/1024 > > | | > > |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 = 2/1/1024 > > | | > > +--------->| GET /path Token 0xf1 Block2 3/0/1024 > > | | > > |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 = 3/0/1024 > > > > Confirmable ACK responses not displayed, nor Etag, Size2 or Maxage. > > > > Now with some packet loss. > > Observe triggered > > |<---------+ 2.05 Token 0xf0 Observe 1236 Block2 = 0/1/1024 > > | | > > +--------->| GET /path Token 0xf2 Block2 1/1/1024 > > | | > > | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 = 1/1/1024 > > | | > > Timeout > > Retry if Confirmable > > +--------->| GET /path Token 0xf2 Block2 1/1/1024 > > | | > > | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 = 1/1/1024 > > | | > > Retries continue - eventually timing out and possibly killing CoAP = session. > > > > Communications can be locked out for 90 seconds as CoAP NSTART is 1. > > > > [DOTS uses NON-Confirmable for protocol reliability, not traffic = reliability] > > > > If not using Confirmable, then the Client needs to time out at the > application layer and retry, but can only go forward 1 block at a time = (does > not have to be in sequential order). > > Server may need to garbage collect on resource with Etag. > > > > What may help the situation (but client can decide when current > Etag/Maxage is no longer valid and stop continue requesting, and = server > may still need to garbage collect) > > > > New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on > client doing GET to get the next block synchronously. > > > > > > CLIENT SERVER > > | | > > +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 = 0/0/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 0/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 1/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 2/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 3/0/1024 > > Observe triggered > > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 = 0/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 = 1/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 = 2/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 = 3/0/1024 > > Observe triggered > > |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 = 0/1/1024 > > | | > > | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 = 1/1/1024 > > | | > > | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 = 2/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 = 3/0/1024 > > Client realises blocks are missing and asks for the missing ones in = one go > > +--------->| GET /path Token 0xf1 NonBlock2 1/0/1024 = NonBlock2 > 2/0/1024 > > | | > > | X<-----+ 2.05 Token 0xf1 Observe 1236 NonBlock2 = 1/1/1024 > > | | > > |<---------+ 2.05 Token 0xf1 Observe 1236 NonBlock2 = 2/1/1024 > > Get final missing block > > +--------->| GET /path Token 0xf2 NonBlock2 1/0/1024 > > | | > > |<---------+ 2.05 Token 0xf2 Observe 1236 NonBlock2 = 1/1/1024 > > > > Obviously the 3 second minimum for RTT calculations needs to be > maintained so that the Attack situation is not made worse. However, I = think > it acceptable that all the NonBlock2s for a particular data set are = all sent as a > stream. > > > > > > > >> -----Original Message----- > >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > >> Sent: 08 April 2020 10:56 > >> To: Carsten Bormann > >> Cc: Jon Shallow; dots@ietf.org; core > >> Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > >> New BLOCK Option? > >> > >> Hi Carsten, > >> > >> We are also considering how to solve the issue at the DOTS level. = The > good > >> news is that we are not blindly overriding pieces of data that are = received > in > >> distinct responses. We have some checks to update an active record. = But > as > >> mentioned by Jon, there are some challenges as well. > >> > >> With regards to the network environment, the direction of the = attack is > the > >> same as the one from servers to clients. That=E2=80=99s said, = telemetry data can > be > >> exchanged in both directions: > >> > >> * from client to servers: using a dedicated telemetry message or in = an > >> efficacy update shared with the server when a mitigation is active. = This is > >> done using PUT messages. > >> * from servers to clients: telemetry data can be sent in dedicated > >> notification messages or as part of the mitigation status update. = Both rely > >> upon GET+Observe. Having a mechanism to ask for gaps would thus be > >> helpful. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Carsten Bormann [mailto:cabo@tzi.org] > >>> Envoy=C3=A9 : mardi 7 avril 2020 23:19 > >>> =C3=80 : Achim Kraus > >>> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; core; dots@ietf.org > >>> Objet : Re: [core] [Dots] Large asynchronous notifications under = DDoS: > >>> New BLOCK Option? > >>> > >>> Hi Achim, > >>> > >>> On 2020-04-07, at 21:04, Achim Kraus wrote: > >>>> > >>>> FMPOV, the first thing to ensure is, that the "large payload" = gets > >>> split > >>>> into "application blocks", which could be processed even when = other > >>>> application blocks are missing. > >>> > >>> Indeed, =E2=80=9Capplication layer framing=E2=80=9D comes to mind = here; that is always > >>> a good idea if it cannot be ensured that all messages make it or = if it > >>> is good to be able to process messages while still waiting for = others. > >>> > >>> .oOo. > >>> > >>> I=E2=80=99m trying to understand the very specific network = environment that we > >>> are targeting here. > >>> Are we assuming packets are way more likely to make it from the = server > >>> to the client than the other way around? > >>> That indeed would call for additional capabilities that base CoAP = does > >>> not have. > >>> We also may not really care about congestion control much in a > >>> situation of massive (attacker-induced) congestion (although that > >>> might be misdiagnosed, so some care is still required); which = would be > >>> another reason to maybe deviate from base CoAP. > >>> > >>> I don=E2=80=99t have a design in mind at the moment. It would = need to cater > >>> for the fact that sending the other response messages for the = request > >>> would be on the initiative of the server. > >>> So observe (with non-confirmable responses) is maybe a good model > >>> indeed; what=E2=80=99s missing is some way to ask for gaps. > >>> > >>> I just resubmitted a draft that we have been discussing for a = while in > >>> T2TRG: > >>> The Series Transfer Pattern (STP) > >>> https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html > >>> > >>> This has some discussion that may be relevant here, although it = does > >>> not address the specific DOTS problem. I think it would be great = if > >>> whatever we come up with to solve this problem would also be a = step > >>> forward on the larger class of applications needing the series > >>> transfer pattern. > >>> > >>> Gr=C3=BC=C3=9Fe, Carsten > >> > >> _______________________________________________ > >> Dots mailing list > >> Dots@ietf.org > >> https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 8 12:48:30 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 818BD3A0ED7; Wed, 8 Apr 2020 12:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4IccYmFodxqH; Wed, 8 Apr 2020 12:48:23 -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 E54A33A1638; Wed, 8 Apr 2020 12:48:21 -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 1jMGgK-0007UI-En; Wed, 08 Apr 2020 20:48:16 +0100 From: "Jon Shallow" To: "'Achim Kraus'" , , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> In-Reply-To: Date: Wed, 8 Apr 2020 20:48:21 +0100 Message-ID: <02b001d60dde$a8772650$f96572f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXQLOrs3hARxTHZOooAydoA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 19:48:26 -0000 Hi Achim, Having the DOTS CBOR data wrapped in CoAP and then wrapped in CoAP is = interesting and could be a way forward here as it gives a lot of = flexibility. As mentioned in my previous response, looking at your suggestion, = "Observe abc" or "Observe abd" are not really needed and could be = replaced "Etag abc" and "Etag abd" respectively.=20 Then with the GET to request the missing blocks could also include the = appropriate Etag to make sure that the correct blocks for the resource = are being asked for. Then it may be possible to not have the double CoAP layer and just have = the NonBlock2 option. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus > Sent: 08 April 2020 19:56 > To: Jon Shallow; mohamed.boucadair@orange.com; cabo@tzi.org; > dots@ietf.org; core@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Jon, >=20 > let me try to demonstrate, how =E2=80=9Capplication layer = framing=E2=80=9D could look like: >=20 > > New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on > client doing GET to get the next block synchronously. > > > > > CLIENT SERVER > > | | > > +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 = 0/0/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 0/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 1/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 2/1/1024 > > | | > > |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 = 3/0/1024 > Do these messages in the application layer -> encode the messages =3D> = put > the encoded message as payload for ordinary notifies: >=20 > CLIENT SERVER > | | > +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 = 0/0/1024 > | | > |<---------+ 2.05 Token 0xf0 Observe 1234 { 2.05 Token > 0xf0 Observe abc NonBlock2 0/1/1024 } > | | > |<---------+ 2.05 Token 0xf0 Observe 1235 { 2.05 Token > 0xf0 Observe abc NonBlock2 1/1/1024 } > | | > |<---------+ 2.05 Token 0xf0 Observe 1236 { 2.05 Token > 0xf0 Observe abc NonBlock2 2/1/1024 } > | | > |<---------+ 2.05 Token 0xf0 Observe 1237 { 2.05 Token > 0xf0 Observe abc NonBlock2 3/0/1024 } >=20 > The outer notifies will be processed as usual, the application block > logic is yours. >=20 > Observe triggered > |<---------+ 2.05 Token 0xf0 Observe 1238 { 2.05 Token > 0xf0 Observe abd NonBlock2 0/1/1024 } > | | > |<---------+ 2.05 Token 0xf0 Observe 1239 { 2.05 Token > 0xf0 Observe abd NonBlock2 1/1/1024 } > | | > |<---------+ 2.05 Token 0xf0 Observe 1240 { 2.05 Token > 0xf0 Observe abd NonBlock2 2/1/1024 } > | | > |<---------+ 2.05 Token 0xf0 Observe 1241 { 2.05 Token > 0xf0 Observe abd NonBlock2 3/0/1024 } >=20 > Observe triggered > |<---------+ 2.05 Token 0xf0 Observe 1238 { 2.05 Token > 0xf0 Observe abd NonBlock2 0/1/1024 } > | | > | X<------+ 2.05 Token 0xf0 Observe 1239 { 2.05 Token > 0xf0 Observe abd NonBlock2 1/1/1024 } > | | > | X<------+ 2.05 Token 0xf0 Observe 1240 { 2.05 Token > 0xf0 Observe abd NonBlock2 2/1/1024 } > | | > |<---------+ 2.05 Token 0xf0 Observe 1241 { 2.05 Token > 0xf0 Observe abd NonBlock2 3/0/1024 } >=20 >=20 > Client realises blocks are missing and asks for the missing ones in = one go >=20 > +--------->| GET /path/ctrl Token 0xf1 { NonBlock2 > 1/0/1024 NonBlock2 2/0/1024 } > | | > | X<------+ 2.05 Token 0xf0 Observe 1242 { 2.05 Token > 0xf0 Observe abd NonBlock2 1/1/1024 } > | | > |<...------+ 2.05 Token 0xf0 Observe 1243 { 2.05 Token > 0xf0 Observe abd NonBlock2 2/1/1024 } >=20 > Get final missing block > +--------->| GET /path/ctrl Token 0xf2 { / NonBlock2 > 1/0/1024 } > | | > |<...------+ 2.05 Token 0xf0 Observe 1244 { 2.05 Token > 0xf0 Observe abd NonBlock2 1/1/1024 } >=20 >=20 > That should be not considered as "precise description of the = application > layer framing". It should just give a first impression, how coap > standards could be used, and the specific stuff could be move to the > application layer (reusing coap again). >=20 > best regards > Achim >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 8 14:04:35 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 2C9813A1811; Wed, 8 Apr 2020 14:04:23 -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, 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 0tuGpa_sarpe; Wed, 8 Apr 2020 14:04: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 69C653A1805; Wed, 8 Apr 2020 14:04:21 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 48yGx012vfz5wD6; Wed, 8 Apr 2020 23:04:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586379860; bh=I8ENY+uiKQGq7nxNLYKwSproOJYHqUrg72VYlyuhVyQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FIq8AOx0hNfv1C0QTPbrTUI5gSSpWbiuGPx/MgsNEUWlpAXfp271QSEwZVdVxNjvs Ch9HrvMZPQ2D6oCaXGCF/W/H+BOGwEn8nhCLDzXbbrbL6oy8ZQ6ZedoY3Wz691dGar srAc96TIj6CvKl9WctDg9ntTgrRJm0kucwAwWsJlfBLpsf2KPYimZye4cK+OAOnshp o6PEnPC2sFoF2rFI7tIzsxVBgrUTOl1GBkobaEyhNWqpWnWXHpB6pPEPETTJYKlU7E I/PQezsMCgWA2MBZR0ivsQT2GMs+cGUqnaDtMqvaOnMMsJcfBXaNpAyg26tnpP9+mL tnwlL40vuWeyw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48yGwz6w3PzBrLb; Wed, 8 Apr 2020 23:04:19 +0200 (CEST) From: To: Achim Kraus , Jon Shallow , "cabo@tzi.org" , "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDelFWvaG9gBmdUOVx/wmUdafbw== Date: Wed, 8 Apr 2020 21:04:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 21:04:30 -0000 SGkgQWNoaW0sIA0KDQpPbmUgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbjoNCg0KPiAgICAgICAgICAg ICArLS0tLS0tLS0tPnwgICBHRVQgL3BhdGgvY3RybCBUb2tlbiAweGYxIHsgTm9uQmxvY2syDQo+ IDEvMC8xMDI0IE5vbkJsb2NrMiAyLzAvMTAyNCB9DQoNCkRvIGV4aXN0aW5nIENvQVAgaW1wbGVt ZW50YXRpb25zIChsaWJjb2FwLCBmb3IgZXhhbXBsZSkgc3VwcG9ydCBHRVRzIHdpdGggYSBwYXls b2FkPw0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4g RGXCoDogQWNoaW0gS3JhdXMgW21haWx0bzphY2hpbWtyYXVzQGdteC5uZXRdDQo+IEVudm95w6nC oDogbWVyY3JlZGkgOCBhdnJpbCAyMDIwIDIwOjU2DQo+IMOAwqA6IEpvbiBTaGFsbG93OyBCT1VD QURBSVIgTW9oYW1lZCBUR0kvT0xOOyBjYWJvQHR6aS5vcmc7DQo+IGRvdHNAaWV0Zi5vcmc7IGNv cmVAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtjb3JlXSBbRG90c10gTGFyZ2UgYXN5bmNocm9u b3VzIG5vdGlmaWNhdGlvbnMgdW5kZXIgRERvUzoNCj4gTmV3IEJMT0NLIE9wdGlvbj8NCj4gDQo+ IEhpIEpvbiwNCj4gDQo+IGxldCBtZSB0cnkgdG8gZGVtb25zdHJhdGUsIGhvdyDigJxhcHBsaWNh dGlvbiBsYXllciBmcmFtaW5n4oCdIGNvdWxkIGxvb2sNCj4gbGlrZToNCj4gDQo+ID4gTmV3IENv QVAgT3B0aW9uIE5PTkJMT0NLMiBlcXVpdmFsZW50IHRvIEJMT0NLMiwgYnV0IGRvZXMgbm90IHJl bHkgb24NCj4gY2xpZW50IGRvaW5nIEdFVCB0byBnZXQgdGhlIG5leHQgYmxvY2sgc3luY2hyb25v dXNseS4gPg0KPiA+DQo+ID4gICAgICAgICBDTElFTlQgICAgICBTRVJWRVINCj4gPiAgICAgICAg ICAgfCAgICAgICAgICB8DQo+ID4gICAgICAgICAgICstLS0tLS0tLS0+fCAgIEdFVCAvcGF0aCBU b2tlbiAweGYwIE9ic2VydmUgMCBOb25CbG9jazINCj4gMC8wLzEwMjQNCj4gPiAgICAgICAgICAg fCAgICAgICAgICB8DQo+ID4gICAgICAgICAgIHw8LS0tLS0tLS0tKyAgIDIuMDUgVG9rZW4gMHhm MCBPYnNlcnZlIDEyMzQgTm9uQmxvY2syDQo+IDAvMS8xMDI0DQo+ID4gICAgICAgICAgIHwgICAg ICAgICAgfA0KPiA+ICAgICAgICAgICB8PC0tLS0tLS0tLSsgICAyLjA1IFRva2VuIDB4ZjAgT2Jz ZXJ2ZSAxMjM0IE5vbkJsb2NrMg0KPiAxLzEvMTAyNA0KPiA+ICAgICAgICAgICB8ICAgICAgICAg IHwNCj4gPiAgICAgICAgICAgfDwtLS0tLS0tLS0rICAgMi4wNSBUb2tlbiAweGYwIE9ic2VydmUg MTIzNCBOb25CbG9jazINCj4gMi8xLzEwMjQNCj4gPiAgICAgICAgICAgfCAgICAgICAgICB8DQo+ ID4gICAgICAgICAgIHw8LS0tLS0tLS0tKyAgIDIuMDUgVG9rZW4gMHhmMCBPYnNlcnZlIDEyMzQg Tm9uQmxvY2syDQo+IDMvMC8xMDI0DQo+IERvIHRoZXNlIG1lc3NhZ2VzIGluIHRoZSBhcHBsaWNh dGlvbiBsYXllciAtPiBlbmNvZGUgdGhlIG1lc3NhZ2VzID0+DQo+IHB1dA0KPiB0aGUgZW5jb2Rl ZCBtZXNzYWdlIGFzIHBheWxvYWQgZm9yIG9yZGluYXJ5IG5vdGlmaWVzOg0KPiANCj4gICAgICAg ICAgIENMSUVOVCAgICAgIFNFUlZFUg0KPiAgICAgICAgICAgICB8ICAgICAgICAgIHwNCj4gICAg ICAgICAgICAgKy0tLS0tLS0tLT58ICAgR0VUIC9wYXRoIFRva2VuIDB4ZjAgT2JzZXJ2ZSAwIE5v bkJsb2NrMg0KPiAwLzAvMTAyNA0KPiAgICAgICAgICAgICB8ICAgICAgICAgIHwNCj4gICAgICAg ICAgICAgfDwtLS0tLS0tLS0rICAgMi4wNSBUb2tlbiAweGYwIE9ic2VydmUgMTIzNCB7IDIuMDUg VG9rZW4NCj4gMHhmMCBPYnNlcnZlIGFiYyBOb25CbG9jazIgMC8xLzEwMjQgfQ0KPiAgICAgICAg ICAgICB8ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgfDwtLS0tLS0tLS0rICAgMi4wNSBUb2tl biAweGYwIE9ic2VydmUgMTIzNSB7IDIuMDUgVG9rZW4NCj4gMHhmMCBPYnNlcnZlIGFiYyBOb25C bG9jazIgMS8xLzEwMjQgfQ0KPiAgICAgICAgICAgICB8ICAgICAgICAgIHwNCj4gICAgICAgICAg ICAgfDwtLS0tLS0tLS0rICAgMi4wNSBUb2tlbiAweGYwIE9ic2VydmUgMTIzNiB7IDIuMDUgVG9r ZW4NCj4gMHhmMCBPYnNlcnZlIGFiYyBOb25CbG9jazIgMi8xLzEwMjQgfQ0KPiAgICAgICAgICAg ICB8ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgfDwtLS0tLS0tLS0rICAgMi4wNSBUb2tlbiAw eGYwIE9ic2VydmUgMTIzNyB7IDIuMDUgVG9rZW4NCj4gMHhmMCBPYnNlcnZlIGFiYyBOb25CbG9j azIgMy8wLzEwMjQgfQ0KPiANCj4gVGhlIG91dGVyIG5vdGlmaWVzIHdpbGwgYmUgcHJvY2Vzc2Vk IGFzIHVzdWFsLCB0aGUgYXBwbGljYXRpb24gYmxvY2sNCj4gbG9naWMgaXMgeW91cnMuDQo+IA0K PiBPYnNlcnZlIHRyaWdnZXJlZA0KPiAgICAgICAgICAgICB8PC0tLS0tLS0tLSsgICAyLjA1IFRv a2VuIDB4ZjAgT2JzZXJ2ZSAxMjM4IHsgMi4wNSBUb2tlbg0KPiAweGYwIE9ic2VydmUgYWJkIE5v bkJsb2NrMiAwLzEvMTAyNCB9DQo+ICAgICAgICAgICAgIHwgICAgICAgICAgfA0KPiAgICAgICAg ICAgICB8PC0tLS0tLS0tLSsgICAyLjA1IFRva2VuIDB4ZjAgT2JzZXJ2ZSAxMjM5IHsgMi4wNSBU b2tlbg0KPiAweGYwIE9ic2VydmUgYWJkIE5vbkJsb2NrMiAxLzEvMTAyNCB9DQo+ICAgICAgICAg ICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICB8PC0tLS0tLS0tLSsgICAyLjA1IFRva2Vu IDB4ZjAgT2JzZXJ2ZSAxMjQwIHsgMi4wNSBUb2tlbg0KPiAweGYwIE9ic2VydmUgYWJkIE5vbkJs b2NrMiAyLzEvMTAyNCB9DQo+ICAgICAgICAgICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAg ICB8PC0tLS0tLS0tLSsgICAyLjA1IFRva2VuIDB4ZjAgT2JzZXJ2ZSAxMjQxIHsgMi4wNSBUb2tl bg0KPiAweGYwIE9ic2VydmUgYWJkIE5vbkJsb2NrMiAzLzAvMTAyNCB9DQo+IA0KPiBPYnNlcnZl IHRyaWdnZXJlZA0KPiAgICAgICAgICAgICB8PC0tLS0tLS0tLSsgICAyLjA1IFRva2VuIDB4ZjAg T2JzZXJ2ZSAxMjM4IHsgMi4wNSBUb2tlbg0KPiAweGYwIE9ic2VydmUgYWJkIE5vbkJsb2NrMiAw LzEvMTAyNCB9DQo+ICAgICAgICAgICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICB8ICBY PC0tLS0tLSsgICAyLjA1IFRva2VuIDB4ZjAgT2JzZXJ2ZSAxMjM5IHsgMi4wNSBUb2tlbg0KPiAw eGYwIE9ic2VydmUgYWJkIE5vbkJsb2NrMiAxLzEvMTAyNCB9DQo+ICAgICAgICAgICAgIHwgICAg ICAgICAgfA0KPiAgICAgICAgICAgICB8ICBYPC0tLS0tLSsgICAyLjA1IFRva2VuIDB4ZjAgT2Jz ZXJ2ZSAxMjQwIHsgMi4wNSBUb2tlbg0KPiAweGYwIE9ic2VydmUgYWJkIE5vbkJsb2NrMiAyLzEv MTAyNCB9DQo+ICAgICAgICAgICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICB8PC0tLS0t LS0tLSsgICAyLjA1IFRva2VuIDB4ZjAgT2JzZXJ2ZSAxMjQxIHsgMi4wNSBUb2tlbg0KPiAweGYw IE9ic2VydmUgYWJkIE5vbkJsb2NrMiAzLzAvMTAyNCB9DQo+IA0KPiANCj4gQ2xpZW50IHJlYWxp c2VzIGJsb2NrcyBhcmUgbWlzc2luZyBhbmQgYXNrcyBmb3IgdGhlIG1pc3Npbmcgb25lcyBpbg0K PiBvbmUgZ28NCj4gDQo+ICAgICAgICAgICAgICstLS0tLS0tLS0+fCAgIEdFVCAvcGF0aC9jdHJs IFRva2VuIDB4ZjEgeyBOb25CbG9jazINCj4gMS8wLzEwMjQgTm9uQmxvY2syIDIvMC8xMDI0IH0N Cj4gICAgICAgICAgICAgfCAgICAgICAgICB8DQo+ICAgICAgICAgICAgIHwgIFg8LS0tLS0tKyAg IDIuMDUgVG9rZW4gMHhmMCBPYnNlcnZlIDEyNDIgeyAyLjA1IFRva2VuDQo+IDB4ZjAgT2JzZXJ2 ZSBhYmQgTm9uQmxvY2syIDEvMS8xMDI0IH0NCj4gICAgICAgICAgICAgfCAgICAgICAgICB8DQo+ ICAgICAgICAgICAgIHw8Li4uLS0tLS0tKyAgIDIuMDUgVG9rZW4gMHhmMCBPYnNlcnZlIDEyNDMg eyAyLjA1IFRva2VuDQo+IDB4ZjAgT2JzZXJ2ZSBhYmQgTm9uQmxvY2syIDIvMS8xMDI0IH0NCj4g DQo+IEdldCBmaW5hbCBtaXNzaW5nIGJsb2NrDQo+ICAgICAgICAgICAgICstLS0tLS0tLS0+fCAg IEdFVCAvcGF0aC9jdHJsIFRva2VuIDB4ZjIgeyAvIE5vbkJsb2NrMg0KPiAxLzAvMTAyNCB9DQo+ ICAgICAgICAgICAgIHwgICAgICAgICAgfA0KPiAgICAgICAgICAgICB8PC4uLi0tLS0tLSsgICAy LjA1IFRva2VuIDB4ZjAgT2JzZXJ2ZSAxMjQ0IHsgMi4wNSBUb2tlbg0KPiAweGYwIE9ic2VydmUg YWJkIE5vbkJsb2NrMiAxLzEvMTAyNCB9DQo+IA0KPiANCj4gVGhhdCBzaG91bGQgYmUgbm90IGNv bnNpZGVyZWQgYXMgInByZWNpc2UgZGVzY3JpcHRpb24gb2YgdGhlDQo+IGFwcGxpY2F0aW9uDQo+ IGxheWVyIGZyYW1pbmciLiBJdCBzaG91bGQganVzdCBnaXZlIGEgZmlyc3QgaW1wcmVzc2lvbiwg aG93IGNvYXANCj4gc3RhbmRhcmRzIGNvdWxkIGJlIHVzZWQsIGFuZCB0aGUgc3BlY2lmaWMgc3R1 ZmYgY291bGQgYmUgbW92ZSB0byB0aGUNCj4gYXBwbGljYXRpb24gbGF5ZXIgKHJldXNpbmcgY29h cCBhZ2FpbikuDQo+IA0KPiBiZXN0IHJlZ2FyZHMNCj4gQWNoaW0NCg== From nobody Wed Apr 8 14:08:30 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 765583A17C6; Wed, 8 Apr 2020 14:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VOJrdyr-1WOU; Wed, 8 Apr 2020 14:08:20 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE8F3A17E3; Wed, 8 Apr 2020 14:08:14 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48yH1R03QMzyT0; Wed, 8 Apr 2020 23:08:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 8 Apr 2020 23:08:10 +0200 Cc: Achim Kraus , Jon Shallow , "dots@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 608072890.381826-2521fb7b4e9194e277f07d5e6f9497e0 Content-Transfer-Encoding: quoted-printable Message-Id: <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 21:08:25 -0000 On 2020-04-08, at 23:04, = wrote: >=20 > Do existing CoAP implementations (libcoap, for example) support GETs = with a payload? That is what FETCH is for. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 8 14:22: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 5F5B33A1790; Wed, 8 Apr 2020 14:22:30 -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, 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 ZjdSSdBNbTKO; Wed, 8 Apr 2020 14:22:29 -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 3DE073A178B; Wed, 8 Apr 2020 14:22:29 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48yHKv1R5PzFqFy; Wed, 8 Apr 2020 23:22:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586380947; bh=yu+mh50kLaOUqiB0jIJreP+NlsFGd3sFBIv0UkwqL/I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=nDQWayBBYnfjZA6l7ERuewHHYwhAwKxdk77nxXIJpe98UBxKFnKuwy+FALJM2AIG+ umVHr7friMBT8ESwdTMccGwYKCluJ3is+XcWyiBKvpasCDQ2/AxyRE0RTw28tzJ+vI QXjZvi04zMAYYq/LFxkvwa0PdErgstzWBUPPP8hIvU1FSSxdIgKuSVDixux2aOA+am bSYT1fdSom4LQZmTOkAB+LJoboie5NRcrFQvJtxm3DNCRcjp8OGXszKOX7Q30YzNFX htZpf624JM0YRsvRbySpLwE9cUjZ/TLqFumYx4IuzX4d/03g4BPB9wCZnIEJj1B6/X 79iy+HWcQm44g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48yHKv0Ck1zBrLT; Wed, 8 Apr 2020 23:22:27 +0200 (CEST) From: To: Carsten Bormann , Achim Kraus CC: Jon Shallow , "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDevNWUFkr+PIL0yEshhdX/J8nw== Date: Wed, 8 Apr 2020 21:22:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> In-Reply-To: <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> 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] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 21:22:30 -0000 UmUtLA0KDQpUaGFua3MsIENhcnN0ZW4uIA0KDQpUaGlzIHdvdWxkIG1lYW4gdGhhdCBsZWdhY3kg Q29BUCBpbXBsZW1zIGRvIG5vdCBzdXBwb3J0IHRoZSBjb2FwLWluLWNvYXAgcHJvcG9zYWwgd2l0 aG91dCBtb2RpZmljYXRpb24gKGdpdmVuIHRoYXQgcmZjODEzMiBzdXBwb3J0IHdpbGwgYmUgcmVx dWlyZWQpLiANCg0KQWN0dWFsbHksIEknbSBzdHJ1Z2dsaW5nIHRvIHVuZGVyc3RhbmQgd2hhdCBw cm9ibGVtIGlzIHNvbHZlZCBieSBkZWZpbmluZyB0aGUgTm9uQmxvY2syIG9wdGlvbiBidXQgdXNl IGl0IG9ubHkgd2l0aCBhbiBleHRyYSBjb2FwIGxheWVyaW5nLiANCg0KQ2hlZXJzLA0KTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IENhcnN0ZW4gQm9ybWFubiBb bWFpbHRvOmNhYm9AdHppLm9yZ10NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSA4IGF2cmlsIDIwMjAg MjM6MDgNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiBDY8KgOiBBY2hpbSBL cmF1czsgSm9uIFNoYWxsb3c7IGRvdHNAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmcNCj4gT2JqZXTC oDogUmU6IFtjb3JlXSBbRG90c10gTGFyZ2UgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMgdW5k ZXIgRERvUzoNCj4gTmV3IEJMT0NLIE9wdGlvbj8NCj4gDQo+IE9uIDIwMjAtMDQtMDgsIGF0IDIz OjA0LCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gRG8gZXhpc3RpbmcgQ29BUCBpbXBsZW1lbnRh dGlvbnMgKGxpYmNvYXAsIGZvciBleGFtcGxlKSBzdXBwb3J0IEdFVHMNCj4gd2l0aCBhIHBheWxv YWQ/DQo+IA0KPiBUaGF0IGlzIHdoYXQgRkVUQ0ggaXMgZm9yLg0KPiANCj4gR3LDvMOfZSwgQ2Fy c3Rlbg0KDQo= From nobody Wed Apr 8 23:00: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 F19503A0BCC; Wed, 8 Apr 2020 22:59:49 -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 (1024-bit key) header.d=gmx.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 1TL6C_rQ1Pxq; Wed, 8 Apr 2020 22:59:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 2DA453A0BC9; Wed, 8 Apr 2020 22:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586411973; bh=aXFWUQ0Cr6fxk0IGCpDmkoQWM5981h3kBu7yCNoRQMA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=LQbbfh36o5LVWE+zV+SIS6wlLuV4dkS96kLiwz9ml+Y8MTjmzpsWkO8ya2UsloLso 40UxqYKcWNeDWciiKHhoKup8QY+RH6V16v2rPDFTrDMaDGcgfw9HtjXpKJ+eUIsGQf JiCg+j5zbrfMu8TiZrjzrOxsrsDIfNWzxGVkL9Fg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([94.216.236.121]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N17UW-1jAlKx0SEM-012UrP; Thu, 09 Apr 2020 07:59:33 +0200 To: mohamed.boucadair@orange.com, Carsten Bormann Cc: Jon Shallow , "dots@ietf.org" , "core@ietf.org" References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Achim Kraus Message-ID: <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> Date: Thu, 9 Apr 2020 07:59:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:9XDp1UYzXrQfeaF+LvqFzOFzZd5Dn9Vy/MPB+Lm2Oye3ysxl6tf 45bImYiY1Tmoz1XniOsIBB+9uuo7oxn7XfvbaSV1xT+EMuernutthuEXKmozcifO4turuBM aaJeTkYPwA1HANlEwO1EXLPRlQHov0hb6fuF5s10opn8VJjfFl7kRsoMK1inEWH8hPWBUzo a6AGKIrPUvplCiBGEQexQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:ynX/RHIi/kc=:Teu0umPj0Ezj/CqYH0CDDc 53w4SfosFEjPfM08xb4pRFl/V5DXVX4U3de3rmZZjM4dOeU1dxAwC/XlmfKc/5YnqVwbo9cgb xRKtrloXkIDQrKg77+IFGYMG7T8jbKhgN17QroXS3GtTgK1mUtWzVzYGfIJKA1Z45fgJ2kGgf T52IrWunW5LFYGaPq1xZs0U6uFYHtWAenmx4n/xOPuHM/BP+m06vyJANyR9KjYLmwXxybgPLv D34xAPGdzmnPozczfcDfaoRV+jcDs/xMeMe7f0DvqI+phqL+YLg7OmJqoSG/2eBpBUlq2v66B AdDzWbOG64VZg5nBX4vnvoebyneXyNS4k3FfKdD5OVO283SLo+ZMr4R6xlN+6HGc1n3OtWotz Z4UdyuBrIzOHWgJX4SUrY1HJWyYMg9vWZZyAUQd1gBZL8i4vbbKKFdC12sYPbN1gQTyx3YTok KAnGFbkqJntwTgV46ja4vUIjhO+efUG8P/8p1ji2eAKH4k6qEMi7lnxBmotHQ4H5g3uFUVfWd iwnHrJSSnfoEg5HkKxk1+cC/O6b9WH7EWnsCXCEnTjC2uP+vblkZifvjCzGXg8JPzP/g6cFrh paZehMaeJqOuyIb8pm9b3pDYKrxTlLuucEonG4K7XD2f10xbSOj8KC2/l74OEusbMckfKIIni mh5Y03+xOB7NZKN2PMgYhqWaojBSqGWmZ+P4yNdADlGl89kbqKVjQI5xwA8QgDK59lzVi747y 5fqy8GQePWtm0bFf9hOwp7KlU/hI/ElGBdS+NQXYMaU45TA2sng+Sku/1BNii6lB9J004p/Qy 7gxHU5S0vpAlBpTeFKFH9TpyS/8aB/Tl0la9RC5ftOwm2w2yFJ+JKCjC/YAJ5msjCEJ8WM5D9 9gYqV78hI3BB4T/ANWbVZMAWhhL0WYebvOTPRyn8RWtsttW22iMGkYB6+XmcAxjgdQLPoggjO zi0KK18HmzoXKrkJeo0lrZjCh25CzlvzfDEdFVz4x1ZmnA2FJ2AlZX2Lqd34dytL1KjC8DEoR S06UzrIHbVtyLOJvPwR3x0jHrvjhVsN+KGoqV2q3zCXwth1nM75aDRZ+xKF0XAssqNh12fxf2 +MANLa4QnITDdrGuhGlrTLmfEGZprOXohBEdrzQkrz2mZJK5qi2A5k+SxAmGGiM3t1IMHye2l qsqS5aa6mz2e01q9nBJ4hzWzEDTSFJOq8j2vW1PO/5xD2hNehekdaLkJc1pvakXRArwHVzZjr 31jEG//xi/yDOioMU Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 05:59:50 -0000 Hi Med, maybe, we have a different understanding of the CoAP principles. RFC 7252: single request-responses are matched by their tokens, chosen by the client. The server must include that token in it's response and must not make assumptions about it. RFC 7641: single request - multiple responses are matched by their tokens, chosen by the client. The server must include that token in all responses and must not make assumptions about it. RFC 7959: multiple request - multiple responses are used to transmit a large resource using the principals of RFC 7252/7641. RFC 7252 each single block transfer matches the single block request with it's single block response by a token chosen by the client. The server can not assume, that the tokens of several block-requests are related. RFC 7641 "single request - multiple responses" applies only to the head. the download of the left blocks doesn't reuse the token, nor is the server allowed, to make assumptions about the token. =3D> you can't send the follow up blocks, because the token to do so is not defined. It would have been defined by the (missing) client request. If the token of the observe is used, the server makes a assumption and relate request of RFC7959, which are not related by the token. Therefore I asked also about the usage of observer/notify. If a PUT/POST is used, then your transfer looks just pretty much as a blockwise with NSTART-X. The drawback there will be the missing "blocksize" negotiation at the head. If that is acceptable, it should have a chance comparable to the proposal. The NonBlock2 solution is not bad on it's own, but it disrupt the principals for the tokens on the server side, at least in my understanding= . =2D-------------------------------------------------------------------- > One clarification question: >> +--------->| GET /path/ctrl Token 0xf1 { NonBlock2 >> 1/0/1024 NonBlock2 2/0/1024 } > Do existing CoAP implementations (libcoap, for example) support GETs with a payload? I know, it looks a little unfair to point on single items of other example and then make buggy examples on my own :-). But I already admit "That should be not considered as "precise description of the application layer framing"". In fact, there is no outer GET required. The outer request could also be POST. +--------->| POST /path/ctrl Token 0xf1 { GET /path Token cde NonBlock2 1/0/1024 NonBlock2 2/0/1024 } Just to mention, that this request triggers the notifies with the missing block is "application layer convention". You may use whatever definition you want to tell the server to (re-)send notifies with blocks, there is no need of that inner GET request. =2D-------------------------------------------------------------------- best regards Achim Am 08.04.20 um 23:22 schrieb mohamed.boucadair@orange.com: > Re-, > > Thanks, Carsten. > > This would mean that legacy CoAP implems do not support the coap-in-coap= proposal without modification (given that rfc8132 support will be require= d). > > Actually, I'm struggling to understand what problem is solved by definin= g the NonBlock2 option but use it only with an extra coap layering. > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: Carsten Bormann [mailto:cabo@tzi.org] >> Envoy=C3=A9=C2=A0: mercredi 8 avril 2020 23:08 >> =C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN >> Cc=C2=A0: Achim Kraus; Jon Shallow; dots@ietf.org; core@ietf.org >> Objet=C2=A0: Re: [core] [Dots] Large asynchronous notifications under D= DoS: >> New BLOCK Option? >> >> On 2020-04-08, at 23:04, >> wrote: >>> >>> Do existing CoAP implementations (libcoap, for example) support GETs >> with a payload? >> >> That is what FETCH is for. >> >> Gr=C3=BC=C3=9Fe, Carsten > From nobody Thu Apr 9 00:02: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 441B83A09D8; Thu, 9 Apr 2020 00:02: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, 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 Xaekn9Ac5yZ4; Thu, 9 Apr 2020 00:01:59 -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 AB9633A08FC; Thu, 9 Apr 2020 00:01:58 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48yXBX4Yb8z5wH2; Thu, 9 Apr 2020 09:01:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586415716; bh=oRt1o0AGdfdnxpeStMLAopJLRVMOE99tLjBhZ0Z1xQ0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ns/iRVhqjqT/DVIGYUojRo37tQJyJtSQaxF4DL20Ki+TsB8yqGGjLagslHVtiWBYG zSQmY9Xqqcaf0bLVpGUTRveBQWfpqHE7SWpYbPbCzL7lK7CsRLnKErjfsgmwY9lu5p IVLb/zwMqlTbbKu7O9xG4yvpomrIlF/f+TgUNNXOoQTwP+Fn8WjFJNuoR5SyyzcwQr RYWPOLhIpxxUxLswjPx90HxmLurfjzCBZZAWMamVFQ/nNSIQx0e843qogPYCMJBGoc igFOeeQn7mds6+GdF+AIbpOfovX6dKFmqbKm1STMUPAlBbLOG6Be4nwpPRwOSYfN2N Z7oqa++b2qvvw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 48yXBX3FhqzDq7T; Thu, 9 Apr 2020 09:01:56 +0200 (CEST) From: To: Achim Kraus , Carsten Bormann CC: Jon Shallow , "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDjzBnXJOSV44SEOR3rmj1OrhPQ== Date: Thu, 9 Apr 2020 07:01:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> In-Reply-To: <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> 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] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 07:02:00 -0000 SGkgQWNoaW0sDQoNCkZpcnN0LCBJIHdhcyBub3QgbG9va2luZyB0byAibWFrZSB5b3VyIGV4YW1w bGUgYnVnZ3kiLiBJIHdhcyB0cnlpbmcgdG8gdW5kZXJzdGFuZCBob3cgdGhpcyB3b3VsZCB3b3Jr IHdpdGhvdXQgcmVxdWlyaW5nIGNoYW5nZXMgdG8gdGhlIGJhc2Ugc3BlY3MuIFlvdXIgZmVlZGJh Y2sgaXMgaGlnaGx5IGFwcHJlY2lhdGVkIGFuZCB2ZXJ5IHVzZWZ1bC4gVGhhbmsgeW91Lg0KDQpT byBmYXIgd2UgaGF2ZSB0aHJlZSBhcHByb2FjaGVzOg0KDQooMSkgVGhlIHVzZSBvZiBub25ibG9j azIgb3B0aW9uIHdpdGggYSAicmVsYXgiIG9mIHRoZSBiZWhhdmlvciBhdCB0aGUgc2VydmVyIHRv IHNlbmQgdGhlIGZyYWdtZW50cyB3aXRoIHRoZSBzYW1lIHRva2VuIGFuZCB3aXRob3V0IHdhaXRp bmcgZm9yIEdFVHMuIA0KDQooMikgVGhlIHVzZSBvZiBhIHNoaW0gYXBwbGljYXRpb24gYXMgeW91 IHN1Z2dlc3RlZCwgd2hpY2ggcmVxdWlyZXMgYW4gdXBkYXRlIG9uIHRoZSBzZXJ2ZXIgc2lkZSBi dXQgYWxzbyBvbiBob3cgY2xpZW50cyBvbiBob3cgdG8gZmlsbCB0aGUgZ2FwcyAodXNlIG9mIFBV VC9GRVRDSCkuIA0KDQooMykgQSBET1RTIHNwZWNpZmljIGFwcHJvYWNoIHRvIGJ1aWxkIGl0cyBv d24gY2h1bmtzIGFuZCBzaWduYWwgYmxvY2tzIGFzIHBhcnQgb2YgdGhlIENCT1IuIFRoZXNlIGJs b2NrcyBhcmUgaGFuZGxlZCBhcyBhdG9taWMgbm90aWZpY2F0aW9ucy4gSWYgYSBibG9jayBpcyBt aXNzaW5nLCB0aGUgY2xpZW50IGNhbiB1c2UgR0VUK1F1ZXJ5IHRvIHJldHJpZXZlIHRoZSBnYXAu IFdlIGRvbid0IHJlcXVpcmUgYW55IG1vZGlmaWNhdGlvbiBhdCB0aGUgYmFzZSBDb0FQIHNwZWNz LiBUaGUgaXNzdWUgd2l0aCB0aGlzIG9uZSBpcyB0byBkZWNpZGUgd2hhdCBkYXRhIHRvIHB1dCBp biB0aGUgYmxvY2tzIHRvIGF2b2lkIHRoYXQgd2hlbiBhIGJsb2NrIGlzIHBhc3NlZCB0byBvdGhl ciBsYXllcnMsIHRoZSBvdmVyaGVhZHMgd29uJ3QgbGVhZCB0byBmcmFnbWVudGF0aW9uLg0KICAN Ckl0IHNlZW1zIHRvIG1lIHRoYXQgKDIpIGlzIGEgbGl0dGxlIGJpdCBtb3JlIGNvbXBsZXggdnMg KDEpLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IEFjaGltIEtyYXVzIFttYWlsdG86YWNoaW1rcmF1c0BnbXgubmV0XQ0KPiBFbnZvecOp wqA6IGpldWRpIDkgYXZyaWwgMjAyMCAwODowMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBU R0kvT0xOOyBDYXJzdGVuIEJvcm1hbm4NCj4gQ2PCoDogSm9uIFNoYWxsb3c7IGRvdHNAaWV0Zi5v cmc7IGNvcmVAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtjb3JlXSBbRG90c10gTGFyZ2UgYXN5 bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMgdW5kZXIgRERvUzoNCj4gTmV3IEJMT0NLIE9wdGlvbj8N Cj4gDQo+IEhpIE1lZCwNCj4gDQo+IG1heWJlLCB3ZSBoYXZlIGEgZGlmZmVyZW50IHVuZGVyc3Rh bmRpbmcgb2YgdGhlIENvQVAgcHJpbmNpcGxlcy4NCj4gDQo+IFJGQyA3MjUyOg0KPiBzaW5nbGUg cmVxdWVzdC1yZXNwb25zZXMgYXJlIG1hdGNoZWQgYnkgdGhlaXIgdG9rZW5zLCBjaG9zZW4gYnkg dGhlDQo+IGNsaWVudC4gVGhlIHNlcnZlciBtdXN0IGluY2x1ZGUgdGhhdCB0b2tlbiBpbiBpdCdz IHJlc3BvbnNlIGFuZCBtdXN0DQo+IG5vdA0KPiBtYWtlIGFzc3VtcHRpb25zIGFib3V0IGl0Lg0K PiANCj4gUkZDIDc2NDE6DQo+IHNpbmdsZSByZXF1ZXN0IC0gbXVsdGlwbGUgcmVzcG9uc2VzIGFy ZSBtYXRjaGVkIGJ5IHRoZWlyIHRva2VucywNCj4gY2hvc2VuDQo+IGJ5IHRoZSBjbGllbnQuIFRo ZSBzZXJ2ZXIgbXVzdCBpbmNsdWRlIHRoYXQgdG9rZW4gaW4gYWxsIHJlc3BvbnNlcyBhbmQNCj4g bXVzdCBub3QgbWFrZSBhc3N1bXB0aW9ucyBhYm91dCBpdC4NCj4gDQo+IFJGQyA3OTU5Og0KPiBt dWx0aXBsZSByZXF1ZXN0IC0gbXVsdGlwbGUgcmVzcG9uc2VzIGFyZSB1c2VkIHRvIHRyYW5zbWl0 IGEgbGFyZ2UNCj4gcmVzb3VyY2UgdXNpbmcgdGhlIHByaW5jaXBhbHMgb2YgUkZDIDcyNTIvNzY0 MS4NCj4gUkZDIDcyNTIgZWFjaCBzaW5nbGUgYmxvY2sgdHJhbnNmZXIgbWF0Y2hlcyB0aGUgc2lu Z2xlIGJsb2NrIHJlcXVlc3QNCj4gd2l0aCBpdCdzIHNpbmdsZSBibG9jayByZXNwb25zZSBieSBh IHRva2VuIGNob3NlbiBieSB0aGUgY2xpZW50LiBUaGUNCj4gc2VydmVyIGNhbiBub3QgYXNzdW1l LCB0aGF0IHRoZSB0b2tlbnMgb2Ygc2V2ZXJhbCBibG9jay1yZXF1ZXN0cyBhcmUNCj4gcmVsYXRl ZC4NCj4gUkZDIDc2NDEgInNpbmdsZSByZXF1ZXN0IC0gbXVsdGlwbGUgcmVzcG9uc2VzIiBhcHBs aWVzIG9ubHkgdG8gdGhlDQo+IGhlYWQuDQo+IHRoZSBkb3dubG9hZCBvZiB0aGUgbGVmdCBibG9j a3MgZG9lc24ndCByZXVzZSB0aGUgdG9rZW4sIG5vciBpcyB0aGUNCj4gc2VydmVyIGFsbG93ZWQs IHRvIG1ha2UgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIHRva2VuLg0KPiANCj4gPT4geW91IGNhbid0 IHNlbmQgdGhlIGZvbGxvdyB1cCBibG9ja3MsIGJlY2F1c2UgdGhlIHRva2VuIHRvIGRvIHNvIGlz DQo+IG5vdCBkZWZpbmVkLiBJdCB3b3VsZCBoYXZlIGJlZW4gZGVmaW5lZCBieSB0aGUgKG1pc3Np bmcpIGNsaWVudA0KPiByZXF1ZXN0Lg0KPiBJZiB0aGUgdG9rZW4gb2YgdGhlIG9ic2VydmUgaXMg dXNlZCwgdGhlIHNlcnZlciBtYWtlcyBhIGFzc3VtcHRpb24gYW5kDQo+IHJlbGF0ZSByZXF1ZXN0 IG9mIFJGQzc5NTksIHdoaWNoIGFyZSBub3QgcmVsYXRlZCBieSB0aGUgdG9rZW4uDQo+IA0KPiBU aGVyZWZvcmUgSSBhc2tlZCBhbHNvIGFib3V0IHRoZSB1c2FnZSBvZiBvYnNlcnZlci9ub3RpZnku IElmIGENCj4gUFVUL1BPU1QNCj4gaXMgdXNlZCwgdGhlbiB5b3VyIHRyYW5zZmVyIGxvb2tzIGp1 c3QgcHJldHR5IG11Y2ggYXMgYSBibG9ja3dpc2Ugd2l0aA0KPiBOU1RBUlQtWC4gVGhlIGRyYXdi YWNrIHRoZXJlIHdpbGwgYmUgdGhlIG1pc3NpbmcgImJsb2Nrc2l6ZSINCj4gbmVnb3RpYXRpb24N Cj4gYXQgdGhlIGhlYWQuIElmIHRoYXQgaXMgYWNjZXB0YWJsZSwgaXQgc2hvdWxkIGhhdmUgYSBj aGFuY2UgY29tcGFyYWJsZQ0KPiB0byB0aGUgcHJvcG9zYWwuDQo+IA0KPiBUaGUgTm9uQmxvY2sy IHNvbHV0aW9uIGlzIG5vdCBiYWQgb24gaXQncyBvd24sIGJ1dCBpdCBkaXNydXB0IHRoZQ0KPiBw cmluY2lwYWxzIGZvciB0aGUgdG9rZW5zIG9uIHRoZSBzZXJ2ZXIgc2lkZSwgYXQgbGVhc3QgaW4g bXkNCj4gdW5kZXJzdGFuZGluZy4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gID4gT25lIGNs YXJpZmljYXRpb24gcXVlc3Rpb246DQo+IA0KPiAgPj4gICAgICAgICAgICAgKy0tLS0tLS0tLT58 ICAgR0VUIC9wYXRoL2N0cmwgVG9rZW4gMHhmMSB7IE5vbkJsb2NrMg0KPiAgPj4gMS8wLzEwMjQg Tm9uQmxvY2syIDIvMC8xMDI0IH0NCj4gDQo+ICA+IERvIGV4aXN0aW5nIENvQVAgaW1wbGVtZW50 YXRpb25zIChsaWJjb2FwLCBmb3IgZXhhbXBsZSkgc3VwcG9ydA0KPiBHRVRzDQo+IHdpdGggYSBw YXlsb2FkPw0KPiANCj4gDQo+IEkga25vdywgaXQgbG9va3MgYSBsaXR0bGUgdW5mYWlyIHRvIHBv aW50IG9uIHNpbmdsZSBpdGVtcyBvZiBvdGhlcg0KPiBleGFtcGxlIGFuZCB0aGVuIG1ha2UgYnVn Z3kgZXhhbXBsZXMgb24gbXkgb3duIDotKS4gQnV0IEkgYWxyZWFkeQ0KPiBhZG1pdA0KPiAiVGhh dCBzaG91bGQgYmUgbm90IGNvbnNpZGVyZWQgYXMgInByZWNpc2UgZGVzY3JpcHRpb24gb2YgdGhl DQo+IGFwcGxpY2F0aW9uIGxheWVyIGZyYW1pbmciIi4NCj4gSW4gZmFjdCwgdGhlcmUgaXMgbm8g b3V0ZXIgR0VUIHJlcXVpcmVkLiBUaGUgb3V0ZXIgcmVxdWVzdCBjb3VsZCBhbHNvDQo+IGJlDQo+ IFBPU1QuDQo+IA0KPiAgICAgICAgICAgICAgICstLS0tLS0tLS0+fCAgIFBPU1QgL3BhdGgvY3Ry bCBUb2tlbiAweGYxIHsgR0VUIC9wYXRoDQo+IFRva2VuIGNkZSBOb25CbG9jazIgMS8wLzEwMjQg Tm9uQmxvY2syIDIvMC8xMDI0IH0NCj4gDQo+IA0KPiBKdXN0IHRvIG1lbnRpb24sIHRoYXQgdGhp cyByZXF1ZXN0IHRyaWdnZXJzIHRoZSBub3RpZmllcyB3aXRoIHRoZQ0KPiBtaXNzaW5nIGJsb2Nr IGlzICJhcHBsaWNhdGlvbiBsYXllciBjb252ZW50aW9uIi4gWW91IG1heSB1c2Ugd2hhdGV2ZXIN Cj4gZGVmaW5pdGlvbiB5b3Ugd2FudCB0byB0ZWxsIHRoZSBzZXJ2ZXIgdG8gKHJlLSlzZW5kIG5v dGlmaWVzIHdpdGgNCj4gYmxvY2tzLCB0aGVyZSBpcyBubyBuZWVkIG9mIHRoYXQgaW5uZXIgR0VU IHJlcXVlc3QuDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IGJlc3QgcmVnYXJkcw0KPiBBY2hp bQ0KPiANCj4gQW0gMDguMDQuMjAgdW0gMjM6MjIgc2NocmllYiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tOg0KPiA+IFJlLSwNCj4gPg0KPiA+IFRoYW5rcywgQ2Fyc3Rlbi4NCj4gPg0KPiA+ IFRoaXMgd291bGQgbWVhbiB0aGF0IGxlZ2FjeSBDb0FQIGltcGxlbXMgZG8gbm90IHN1cHBvcnQg dGhlIGNvYXAtaW4tDQo+IGNvYXAgcHJvcG9zYWwgd2l0aG91dCBtb2RpZmljYXRpb24gKGdpdmVu IHRoYXQgcmZjODEzMiBzdXBwb3J0IHdpbGwgYmUNCj4gcmVxdWlyZWQpLg0KPiA+DQo+ID4gQWN0 dWFsbHksIEknbSBzdHJ1Z2dsaW5nIHRvIHVuZGVyc3RhbmQgd2hhdCBwcm9ibGVtIGlzIHNvbHZl ZCBieQ0KPiBkZWZpbmluZyB0aGUgTm9uQmxvY2syIG9wdGlvbiBidXQgdXNlIGl0IG9ubHkgd2l0 aCBhbiBleHRyYSBjb2FwDQo+IGxheWVyaW5nLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0K PiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBDYXJzdGVu IEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQo+ID4+IEVudm95w6nCoDogbWVyY3JlZGkg OCBhdnJpbCAyMDIwIDIzOjA4DQo+ID4+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4N Cj4gPj4gQ2PCoDogQWNoaW0gS3JhdXM7IEpvbiBTaGFsbG93OyBkb3RzQGlldGYub3JnOyBjb3Jl QGlldGYub3JnDQo+ID4+IE9iamV0wqA6IFJlOiBbY29yZV0gW0RvdHNdIExhcmdlIGFzeW5jaHJv bm91cyBub3RpZmljYXRpb25zIHVuZGVyDQo+IEREb1M6DQo+ID4+IE5ldyBCTE9DSyBPcHRpb24/ DQo+ID4+DQo+ID4+IE9uIDIwMjAtMDQtMDgsIGF0IDIzOjA0LCA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4NCj4gPj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0K PiA+Pj4NCj4gPj4+IERvIGV4aXN0aW5nIENvQVAgaW1wbGVtZW50YXRpb25zIChsaWJjb2FwLCBm b3IgZXhhbXBsZSkgc3VwcG9ydA0KPiBHRVRzDQo+ID4+IHdpdGggYSBwYXlsb2FkPw0KPiA+Pg0K PiA+PiBUaGF0IGlzIHdoYXQgRkVUQ0ggaXMgZm9yLg0KPiA+Pg0KPiA+PiBHcsO8w59lLCBDYXJz dGVuDQo+ID4NCg0K From nobody Thu Apr 9 00:17:52 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 CA5C63A0D4B; Thu, 9 Apr 2020 00:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GvdKHp0pE_-E; Thu, 9 Apr 2020 00:17:44 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC643A0D4A; Thu, 9 Apr 2020 00:17:43 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48yXXh6ljjz10Bl; Thu, 9 Apr 2020 09:17:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 9 Apr 2020 09:17:40 +0200 Cc: Achim Kraus , Jon Shallow , "dots@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 608109460.425614-06e3c93157a2d76006260ce2aead921e Content-Transfer-Encoding: quoted-printable Message-Id: <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@tzi.org> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 07:17:47 -0000 I apologize in advance for chiming in before having digested the whole = thread. I think that the idea of using observe with a modified block-wise = protocol (1 below) can work. I also think that application-layer framing (3 below) is useful. I don=E2=80=99t see a contradiction between the two; they might be used = together. I would like to know how to handle two sub-problems here: (a) using non-confirmable responses without additional requests brings = us into PROBING_RATE territory. What is actually the rate at which this = exchange is supposed to happen? Do we have other ways to manage = capacity of the response path (a.k.a. congestion control)? I.e., how = does the server know which rate (e.g., for pacing) it should use for = sending further messages? (b) the semantics of observe is that a notification is the whole new = state of the resource. Proxies will implement it that way. Of course = block2 modifies this semantics a bit, so nonblock2 might do that too. = Still, I think we need to consider what proxies (or client caches) will = make out of the mechanism we devise. Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-09, at 09:01, = wrote: >=20 > Hi Achim, >=20 > First, I was not looking to "make your example buggy". I was trying to = understand how this would work without requiring changes to the base = specs. Your feedback is highly appreciated and very useful. Thank you. >=20 > So far we have three approaches: >=20 > (1) The use of nonblock2 option with a "relax" of the behavior at the = server to send the fragments with the same token and without waiting for = GETs.=20 >=20 > (2) The use of a shim application as you suggested, which requires an = update on the server side but also on how clients on how to fill the = gaps (use of PUT/FETCH).=20 >=20 > (3) A DOTS specific approach to build its own chunks and signal blocks = as part of the CBOR. These blocks are handled as atomic notifications. = If a block is missing, the client can use GET+Query to retrieve the gap. = We don't require any modification at the base CoAP specs. The issue with = this one is to decide what data to put in the blocks to avoid that when = a block is passed to other layers, the overheads won't lead to = fragmentation. >=20 > It seems to me that (2) is a little bit more complex vs (1).=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Achim Kraus [mailto:achimkraus@gmx.net] >> Envoy=C3=A9 : jeudi 9 avril 2020 08:00 >> =C3=80 : BOUCADAIR Mohamed TGI/OLN; Carsten Bormann >> Cc : Jon Shallow; dots@ietf.org; core@ietf.org >> Objet : Re: [core] [Dots] Large asynchronous notifications under = DDoS: >> New BLOCK Option? >>=20 >> Hi Med, >>=20 >> maybe, we have a different understanding of the CoAP principles. >>=20 >> RFC 7252: >> single request-responses are matched by their tokens, chosen by the >> client. The server must include that token in it's response and must >> not >> make assumptions about it. >>=20 >> RFC 7641: >> single request - multiple responses are matched by their tokens, >> chosen >> by the client. The server must include that token in all responses = and >> must not make assumptions about it. >>=20 >> RFC 7959: >> multiple request - multiple responses are used to transmit a large >> resource using the principals of RFC 7252/7641. >> RFC 7252 each single block transfer matches the single block request >> with it's single block response by a token chosen by the client. The >> server can not assume, that the tokens of several block-requests are >> related. >> RFC 7641 "single request - multiple responses" applies only to the >> head. >> the download of the left blocks doesn't reuse the token, nor is the >> server allowed, to make assumptions about the token. >>=20 >> =3D> you can't send the follow up blocks, because the token to do so = is >> not defined. It would have been defined by the (missing) client >> request. >> If the token of the observe is used, the server makes a assumption = and >> relate request of RFC7959, which are not related by the token. >>=20 >> Therefore I asked also about the usage of observer/notify. If a >> PUT/POST >> is used, then your transfer looks just pretty much as a blockwise = with >> NSTART-X. The drawback there will be the missing "blocksize" >> negotiation >> at the head. If that is acceptable, it should have a chance = comparable >> to the proposal. >>=20 >> The NonBlock2 solution is not bad on it's own, but it disrupt the >> principals for the tokens on the server side, at least in my >> understanding. >>=20 >> --------------------------------------------------------------------- >>=20 >>> One clarification question: >>=20 >>>> +--------->| GET /path/ctrl Token 0xf1 { NonBlock2 >>>> 1/0/1024 NonBlock2 2/0/1024 } >>=20 >>> Do existing CoAP implementations (libcoap, for example) support >> GETs >> with a payload? >>=20 >>=20 >> I know, it looks a little unfair to point on single items of other >> example and then make buggy examples on my own :-). But I already >> admit >> "That should be not considered as "precise description of the >> application layer framing"". >> In fact, there is no outer GET required. The outer request could also >> be >> POST. >>=20 >> +--------->| POST /path/ctrl Token 0xf1 { GET /path >> Token cde NonBlock2 1/0/1024 NonBlock2 2/0/1024 } >>=20 >>=20 >> Just to mention, that this request triggers the notifies with the >> missing block is "application layer convention". You may use whatever >> definition you want to tell the server to (re-)send notifies with >> blocks, there is no need of that inner GET request. >>=20 >> --------------------------------------------------------------------- >>=20 >> best regards >> Achim >>=20 >> Am 08.04.20 um 23:22 schrieb mohamed.boucadair@orange.com: >>> Re-, >>>=20 >>> Thanks, Carsten. >>>=20 >>> This would mean that legacy CoAP implems do not support the coap-in- >> coap proposal without modification (given that rfc8132 support will = be >> required). >>>=20 >>> Actually, I'm struggling to understand what problem is solved by >> defining the NonBlock2 option but use it only with an extra coap >> layering. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : Carsten Bormann [mailto:cabo@tzi.org] >>>> Envoy=C3=A9 : mercredi 8 avril 2020 23:08 >>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>> Cc : Achim Kraus; Jon Shallow; dots@ietf.org; core@ietf.org >>>> Objet : Re: [core] [Dots] Large asynchronous notifications under >> DDoS: >>>> New BLOCK Option? >>>>=20 >>>> On 2020-04-08, at 23:04, >>>> wrote: >>>>>=20 >>>>> Do existing CoAP implementations (libcoap, for example) support >> GETs >>>> with a payload? >>>>=20 >>>> That is what FETCH is for. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >=20 From nobody Thu Apr 9 00:56:31 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 23EFE3A0E49; Thu, 9 Apr 2020 00:56:24 -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, 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 AaFqjLhTmwdA; Thu, 9 Apr 2020 00:56:22 -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 B0F203A0E7F; Thu, 9 Apr 2020 00:56:18 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 48yYPD6ChPz2xdY; Thu, 9 Apr 2020 09:56:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586418976; bh=OqvPY1iJf9feuGUREsp4Iyj6RVPKjsqogttI9S1f9zU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=b4aAR0z+ZSLMyfA68Go+P2y5Aq4S6kNHSBTq2y/NyUEPg+BqdREIQGDYlj0+xutk+ C/J51QRZA6R0gCEFjHZJuJGnd5c/TNQY5F+1FFsSxQX3+d8bU3e/QXffpyyAR+vIAN Wp04KanzJTUG0w086IsASVvNYpR4ql97o0kAF4G0ywDMs1k1o5RiyQOJReUYqW1um+ c5d0yvHL+SEdVs4DvdGfoGKpAb3QBJXHmWl01eMuVWYzrRcI3eNiKhE/ep4UwztNIz JPaor6FmkOUQIDMElidp6iubrcyO9QxTjDEmtr5wdyTryPbm8NcXwcyGe0FQZwxGta pe7pafuloOzxw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48yYPD4qJMzCqkv; Thu, 9 Apr 2020 09:56:16 +0200 (CEST) From: To: Carsten Bormann CC: Achim Kraus , Jon Shallow , "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDkRYLU3u6qNWEkiODvNJMBEeOw== Date: Thu, 9 Apr 2020 07:56:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314921C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@tzi.org> In-Reply-To: <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@tzi.org> 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] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 07:56:26 -0000 SGkgQ2Fyc3RlbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogQ2Fyc3RlbiBCb3JtYW5uIFttYWls dG86Y2Fib0B0emkub3JnXQ0KPiBFbnZvecOpwqA6IGpldWRpIDkgYXZyaWwgMjAyMCAwOToxOA0K PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IEFjaGltIEtyYXVzOyBK b24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZzsgY29yZUBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTog W2NvcmVdIFtEb3RzXSBMYXJnZSBhc3luY2hyb25vdXMgbm90aWZpY2F0aW9ucyB1bmRlciBERG9T Og0KPiBOZXcgQkxPQ0sgT3B0aW9uPw0KPiANCj4gSSBhcG9sb2dpemUgaW4gYWR2YW5jZSBmb3Ig Y2hpbWluZyBpbiBiZWZvcmUgaGF2aW5nIGRpZ2VzdGVkIHRoZSB3aG9sZQ0KPiB0aHJlYWQuDQo+ IA0KPiBJIHRoaW5rIHRoYXQgdGhlIGlkZWEgb2YgdXNpbmcgb2JzZXJ2ZSB3aXRoIGEgbW9kaWZp ZWQgYmxvY2std2lzZQ0KPiBwcm90b2NvbCAoMSBiZWxvdykgY2FuIHdvcmsuDQo+IA0KPiBJIGFs c28gdGhpbmsgdGhhdCBhcHBsaWNhdGlvbi1sYXllciBmcmFtaW5nICgzIGJlbG93KSBpcyB1c2Vm dWwuDQo+IA0KPiBJIGRvbuKAmXQgc2VlIGEgY29udHJhZGljdGlvbiBiZXR3ZWVuIHRoZSB0d287 IHRoZXkgbWlnaHQgYmUgdXNlZA0KPiB0b2dldGhlci4NCj4gDQo+IEkgd291bGQgbGlrZSB0byBr bm93IGhvdyB0byBoYW5kbGUgdHdvIHN1Yi1wcm9ibGVtcyBoZXJlOg0KPiANCj4gKGEpIHVzaW5n IG5vbi1jb25maXJtYWJsZSByZXNwb25zZXMgd2l0aG91dCBhZGRpdGlvbmFsIHJlcXVlc3RzIGJy aW5ncw0KPiB1cyBpbnRvIFBST0JJTkdfUkFURSB0ZXJyaXRvcnkuICBXaGF0IGlzIGFjdHVhbGx5 IHRoZSByYXRlIGF0IHdoaWNoDQo+IHRoaXMgZXhjaGFuZ2UgaXMgc3VwcG9zZWQgdG8gaGFwcGVu PyAgRG8gd2UgaGF2ZSBvdGhlciB3YXlzIHRvIG1hbmFnZQ0KPiBjYXBhY2l0eSBvZiB0aGUgcmVz cG9uc2UgcGF0aCAoYS5rLmEuIGNvbmdlc3Rpb24gY29udHJvbCk/ICBJLmUuLCBob3cNCj4gZG9l cyB0aGUgc2VydmVyIGtub3cgd2hpY2ggcmF0ZSAoZS5nLiwgZm9yIHBhY2luZykgaXQgc2hvdWxk IHVzZSBmb3INCj4gc2VuZGluZyBmdXJ0aGVyIG1lc3NhZ2VzPw0KDQpbTWVkXSANCg0KKDEpDQoN ClByb2JpbmcgcmF0ZSBpcyBuZWdvdGlhdGVkIGR1cmluZyBpZGxlIHRpbWUgYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCBzZXJ2ZXI6DQoNCiAgICAgIHByb2JpbmctcmF0ZTogIFRoZSBhdmVyYWdlIGRh dGEgcmF0ZSB0aGF0IG11c3Qgbm90IGJlIGV4Y2VlZGVkIGJ5DQogICAgICAgICBhIERPVFMgYWdl bnQgaW4gc2VuZGluZyB0byBhIHBlZXIgRE9UUyBhZ2VudCB0aGF0IGRvZXMgbm90DQogICAgICAg ICByZXNwb25kIChyZWZlcnJlZCB0byBhcyBQUk9CSU5HX1JBVEUgcGFyYW1ldGVyIGluIENvQVAp Lg0KDQooMikNCg0KVGhlIHByb2JpbmctcmF0ZSB1c2VkIGluIGlkbGUgdGltZSBtYXkgbm90IGJl IHRoZSBzYW1lIGFzIHRoZSBvbmUgdXNpbmcgZHVyaW5nIGF0IGF0dGFjayB0aW1lLiBXZSBkbyBh IHZhbHVlIGZvciBlYWNoIG9mIHRoZW0uDQoNCigzKSBpbiBhZGRpdGlvbiwgd2UgbmVnb3RpYXRl IHRoaXMgYWRkaXRpb25hbCAiZ3VhcmQiOg0KDQogICBET1RTIGFnZW50cyBNVVNUIE5PVCBzZW5k IHByZS1vci1vbmdvaW5nLW1pdGlnYXRpb24gdGVsZW1ldHJ5DQogICBtZXNzYWdlcyB0byB0aGUg c2FtZSBwZWVyIG1vcmUgZnJlcXVlbnRseSB0aGFuIG9uY2UgZXZlcnkgJ3RlbGVtZXRyeS0NCiAg IG5vdGlmeS1pbnRlcnZhbCcNCg0KPiANCj4gKGIpIHRoZSBzZW1hbnRpY3Mgb2Ygb2JzZXJ2ZSBp cyB0aGF0IGEgbm90aWZpY2F0aW9uIGlzIHRoZSB3aG9sZSBuZXcNCj4gc3RhdGUgb2YgdGhlIHJl c291cmNlLiAgUHJveGllcyB3aWxsIGltcGxlbWVudCBpdCB0aGF0IHdheS4gIE9mIGNvdXJzZQ0K PiBibG9jazIgbW9kaWZpZXMgdGhpcyBzZW1hbnRpY3MgYSBiaXQsIHNvIG5vbmJsb2NrMiBtaWdo dCBkbyB0aGF0IHRvby4NCj4gU3RpbGwsIEkgdGhpbmsgd2UgbmVlZCB0byBjb25zaWRlciB3aGF0 IHByb3hpZXMgKG9yIGNsaWVudCBjYWNoZXMpDQo+IHdpbGwgbWFrZSBvdXQgb2YgdGhlIG1lY2hh bmlzbSB3ZSBkZXZpc2UuDQoNCltNZWRdIEFncmVlIGZvciB0aGUgZ2VuZXJpYyBDb0FQIGNhc2Uu IA0KDQpGb3IgdGhlIHBhcnRpY3VsYXIgY2FzZSBvZiBET1RTLCBzZXNzaW9ucyBhcmUgZXN0YWJs aXNoZWQgaG9wLWJ5LWhwIHdoZW4gYSBwcm94eSAod2UgY2FsbGVkIGl0LCBnYXRld2F5KSBpcyBp bnZvbHZlZC4gV2UgaGF2ZSB0aGUgZnVsbCB2aXNpYmlsaXR5IG9uIHdoYXQgaGFwcGVucy4gICAN Cg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4gDQo+ID4gT24gMjAyMC0wNC0wOSwgYXQg MDk6MDEsIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBBY2hpbSwNCj4gPg0KPiA+IEZpcnN0 LCBJIHdhcyBub3QgbG9va2luZyB0byAibWFrZSB5b3VyIGV4YW1wbGUgYnVnZ3kiLiBJIHdhcyB0 cnlpbmcNCj4gdG8gdW5kZXJzdGFuZCBob3cgdGhpcyB3b3VsZCB3b3JrIHdpdGhvdXQgcmVxdWly aW5nIGNoYW5nZXMgdG8gdGhlDQo+IGJhc2Ugc3BlY3MuIFlvdXIgZmVlZGJhY2sgaXMgaGlnaGx5 IGFwcHJlY2lhdGVkIGFuZCB2ZXJ5IHVzZWZ1bC4gVGhhbmsNCj4geW91Lg0KPiA+DQo+ID4gU28g ZmFyIHdlIGhhdmUgdGhyZWUgYXBwcm9hY2hlczoNCj4gPg0KPiA+ICgxKSBUaGUgdXNlIG9mIG5v bmJsb2NrMiBvcHRpb24gd2l0aCBhICJyZWxheCIgb2YgdGhlIGJlaGF2aW9yIGF0DQo+IHRoZSBz ZXJ2ZXIgdG8gc2VuZCB0aGUgZnJhZ21lbnRzIHdpdGggdGhlIHNhbWUgdG9rZW4gYW5kIHdpdGhv dXQNCj4gd2FpdGluZyBmb3IgR0VUcy4NCj4gPg0KPiA+ICgyKSBUaGUgdXNlIG9mIGEgc2hpbSBh cHBsaWNhdGlvbiBhcyB5b3Ugc3VnZ2VzdGVkLCB3aGljaCByZXF1aXJlcw0KPiBhbiB1cGRhdGUg b24gdGhlIHNlcnZlciBzaWRlIGJ1dCBhbHNvIG9uIGhvdyBjbGllbnRzIG9uIGhvdyB0byBmaWxs DQo+IHRoZSBnYXBzICh1c2Ugb2YgUFVUL0ZFVENIKS4NCj4gPg0KPiA+ICgzKSBBIERPVFMgc3Bl Y2lmaWMgYXBwcm9hY2ggdG8gYnVpbGQgaXRzIG93biBjaHVua3MgYW5kIHNpZ25hbA0KPiBibG9j a3MgYXMgcGFydCBvZiB0aGUgQ0JPUi4gVGhlc2UgYmxvY2tzIGFyZSBoYW5kbGVkIGFzIGF0b21p Yw0KPiBub3RpZmljYXRpb25zLiBJZiBhIGJsb2NrIGlzIG1pc3NpbmcsIHRoZSBjbGllbnQgY2Fu IHVzZSBHRVQrUXVlcnkgdG8NCj4gcmV0cmlldmUgdGhlIGdhcC4gV2UgZG9uJ3QgcmVxdWlyZSBh bnkgbW9kaWZpY2F0aW9uIGF0IHRoZSBiYXNlIENvQVANCj4gc3BlY3MuIFRoZSBpc3N1ZSB3aXRo IHRoaXMgb25lIGlzIHRvIGRlY2lkZSB3aGF0IGRhdGEgdG8gcHV0IGluIHRoZQ0KPiBibG9ja3Mg dG8gYXZvaWQgdGhhdCB3aGVuIGEgYmxvY2sgaXMgcGFzc2VkIHRvIG90aGVyIGxheWVycywgdGhl DQo+IG92ZXJoZWFkcyB3b24ndCBsZWFkIHRvIGZyYWdtZW50YXRpb24uDQo+ID4NCj4gPiBJdCBz ZWVtcyB0byBtZSB0aGF0ICgyKSBpcyBhIGxpdHRsZSBiaXQgbW9yZSBjb21wbGV4IHZzICgxKS4N Cj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPj4gRGUgOiBBY2hpbSBLcmF1cyBbbWFpbHRvOmFjaGlta3JhdXNAZ214Lm5l dF0NCj4gPj4gRW52b3nDqSA6IGpldWRpIDkgYXZyaWwgMjAyMCAwODowMA0KPiA+PiDDgCA6IEJP VUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IENhcnN0ZW4gQm9ybWFubg0KPiA+PiBDYyA6IEpvbiBT aGFsbG93OyBkb3RzQGlldGYub3JnOyBjb3JlQGlldGYub3JnDQo+ID4+IE9iamV0IDogUmU6IFtj b3JlXSBbRG90c10gTGFyZ2UgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMgdW5kZXINCj4gRERv UzoNCj4gPj4gTmV3IEJMT0NLIE9wdGlvbj8NCj4gPj4NCj4gPj4gSGkgTWVkLA0KPiA+Pg0KPiA+ PiBtYXliZSwgd2UgaGF2ZSBhIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5nIG9mIHRoZSBDb0FQIHBy aW5jaXBsZXMuDQo+ID4+DQo+ID4+IFJGQyA3MjUyOg0KPiA+PiBzaW5nbGUgcmVxdWVzdC1yZXNw b25zZXMgYXJlIG1hdGNoZWQgYnkgdGhlaXIgdG9rZW5zLCBjaG9zZW4gYnkgdGhlDQo+ID4+IGNs aWVudC4gVGhlIHNlcnZlciBtdXN0IGluY2x1ZGUgdGhhdCB0b2tlbiBpbiBpdCdzIHJlc3BvbnNl IGFuZA0KPiBtdXN0DQo+ID4+IG5vdA0KPiA+PiBtYWtlIGFzc3VtcHRpb25zIGFib3V0IGl0Lg0K PiA+Pg0KPiA+PiBSRkMgNzY0MToNCj4gPj4gc2luZ2xlIHJlcXVlc3QgLSBtdWx0aXBsZSByZXNw b25zZXMgYXJlIG1hdGNoZWQgYnkgdGhlaXIgdG9rZW5zLA0KPiA+PiBjaG9zZW4NCj4gPj4gYnkg dGhlIGNsaWVudC4gVGhlIHNlcnZlciBtdXN0IGluY2x1ZGUgdGhhdCB0b2tlbiBpbiBhbGwgcmVz cG9uc2VzDQo+IGFuZA0KPiA+PiBtdXN0IG5vdCBtYWtlIGFzc3VtcHRpb25zIGFib3V0IGl0Lg0K PiA+Pg0KPiA+PiBSRkMgNzk1OToNCj4gPj4gbXVsdGlwbGUgcmVxdWVzdCAtIG11bHRpcGxlIHJl c3BvbnNlcyBhcmUgdXNlZCB0byB0cmFuc21pdCBhIGxhcmdlDQo+ID4+IHJlc291cmNlIHVzaW5n IHRoZSBwcmluY2lwYWxzIG9mIFJGQyA3MjUyLzc2NDEuDQo+ID4+IFJGQyA3MjUyIGVhY2ggc2lu Z2xlIGJsb2NrIHRyYW5zZmVyIG1hdGNoZXMgdGhlIHNpbmdsZSBibG9jaw0KPiByZXF1ZXN0DQo+ ID4+IHdpdGggaXQncyBzaW5nbGUgYmxvY2sgcmVzcG9uc2UgYnkgYSB0b2tlbiBjaG9zZW4gYnkg dGhlIGNsaWVudC4NCj4gVGhlDQo+ID4+IHNlcnZlciBjYW4gbm90IGFzc3VtZSwgdGhhdCB0aGUg dG9rZW5zIG9mIHNldmVyYWwgYmxvY2stcmVxdWVzdHMNCj4gYXJlDQo+ID4+IHJlbGF0ZWQuDQo+ ID4+IFJGQyA3NjQxICJzaW5nbGUgcmVxdWVzdCAtIG11bHRpcGxlIHJlc3BvbnNlcyIgYXBwbGll cyBvbmx5IHRvIHRoZQ0KPiA+PiBoZWFkLg0KPiA+PiB0aGUgZG93bmxvYWQgb2YgdGhlIGxlZnQg YmxvY2tzIGRvZXNuJ3QgcmV1c2UgdGhlIHRva2VuLCBub3IgaXMgdGhlDQo+ID4+IHNlcnZlciBh bGxvd2VkLCB0byBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSB0b2tlbi4NCj4gPj4NCj4gPj4g PT4geW91IGNhbid0IHNlbmQgdGhlIGZvbGxvdyB1cCBibG9ja3MsIGJlY2F1c2UgdGhlIHRva2Vu IHRvIGRvIHNvDQo+IGlzDQo+ID4+IG5vdCBkZWZpbmVkLiBJdCB3b3VsZCBoYXZlIGJlZW4gZGVm aW5lZCBieSB0aGUgKG1pc3NpbmcpIGNsaWVudA0KPiA+PiByZXF1ZXN0Lg0KPiA+PiBJZiB0aGUg dG9rZW4gb2YgdGhlIG9ic2VydmUgaXMgdXNlZCwgdGhlIHNlcnZlciBtYWtlcyBhIGFzc3VtcHRp b24NCj4gYW5kDQo+ID4+IHJlbGF0ZSByZXF1ZXN0IG9mIFJGQzc5NTksIHdoaWNoIGFyZSBub3Qg cmVsYXRlZCBieSB0aGUgdG9rZW4uDQo+ID4+DQo+ID4+IFRoZXJlZm9yZSBJIGFza2VkIGFsc28g YWJvdXQgdGhlIHVzYWdlIG9mIG9ic2VydmVyL25vdGlmeS4gSWYgYQ0KPiA+PiBQVVQvUE9TVA0K PiA+PiBpcyB1c2VkLCB0aGVuIHlvdXIgdHJhbnNmZXIgbG9va3MganVzdCBwcmV0dHkgbXVjaCBh cyBhIGJsb2Nrd2lzZQ0KPiB3aXRoDQo+ID4+IE5TVEFSVC1YLiBUaGUgZHJhd2JhY2sgdGhlcmUg d2lsbCBiZSB0aGUgbWlzc2luZyAiYmxvY2tzaXplIg0KPiA+PiBuZWdvdGlhdGlvbg0KPiA+PiBh dCB0aGUgaGVhZC4gSWYgdGhhdCBpcyBhY2NlcHRhYmxlLCBpdCBzaG91bGQgaGF2ZSBhIGNoYW5j ZQ0KPiBjb21wYXJhYmxlDQo+ID4+IHRvIHRoZSBwcm9wb3NhbC4NCj4gPj4NCj4gPj4gVGhlIE5v bkJsb2NrMiBzb2x1dGlvbiBpcyBub3QgYmFkIG9uIGl0J3Mgb3duLCBidXQgaXQgZGlzcnVwdCB0 aGUNCj4gPj4gcHJpbmNpcGFscyBmb3IgdGhlIHRva2VucyBvbiB0aGUgc2VydmVyIHNpZGUsIGF0 IGxlYXN0IGluIG15DQo+ID4+IHVuZGVyc3RhbmRpbmcuDQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gLS0NCj4gPj4NCj4gPj4+IE9uZSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOg0KPiA+Pg0KPiA+ Pj4+ICAgICAgICAgICAgKy0tLS0tLS0tLT58ICAgR0VUIC9wYXRoL2N0cmwgVG9rZW4gMHhmMSB7 IE5vbkJsb2NrMg0KPiA+Pj4+IDEvMC8xMDI0IE5vbkJsb2NrMiAyLzAvMTAyNCB9DQo+ID4+DQo+ ID4+PiBEbyBleGlzdGluZyBDb0FQIGltcGxlbWVudGF0aW9ucyAobGliY29hcCwgZm9yIGV4YW1w bGUpIHN1cHBvcnQNCj4gPj4gR0VUcw0KPiA+PiB3aXRoIGEgcGF5bG9hZD8NCj4gPj4NCj4gPj4N Cj4gPj4gSSBrbm93LCBpdCBsb29rcyBhIGxpdHRsZSB1bmZhaXIgdG8gcG9pbnQgb24gc2luZ2xl IGl0ZW1zIG9mIG90aGVyDQo+ID4+IGV4YW1wbGUgYW5kIHRoZW4gbWFrZSBidWdneSBleGFtcGxl cyBvbiBteSBvd24gOi0pLiBCdXQgSSBhbHJlYWR5DQo+ID4+IGFkbWl0DQo+ID4+ICJUaGF0IHNo b3VsZCBiZSBub3QgY29uc2lkZXJlZCBhcyAicHJlY2lzZSBkZXNjcmlwdGlvbiBvZiB0aGUNCj4g Pj4gYXBwbGljYXRpb24gbGF5ZXIgZnJhbWluZyIiLg0KPiA+PiBJbiBmYWN0LCB0aGVyZSBpcyBu byBvdXRlciBHRVQgcmVxdWlyZWQuIFRoZSBvdXRlciByZXF1ZXN0IGNvdWxkDQo+IGFsc28NCj4g Pj4gYmUNCj4gPj4gUE9TVC4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICstLS0tLS0tLS0+fCAg IFBPU1QgL3BhdGgvY3RybCBUb2tlbiAweGYxIHsgR0VUIC9wYXRoDQo+ID4+IFRva2VuIGNkZSBO b25CbG9jazIgMS8wLzEwMjQgTm9uQmxvY2syIDIvMC8xMDI0IH0NCj4gPj4NCj4gPj4NCj4gPj4g SnVzdCB0byBtZW50aW9uLCB0aGF0IHRoaXMgcmVxdWVzdCB0cmlnZ2VycyB0aGUgbm90aWZpZXMg d2l0aCB0aGUNCj4gPj4gbWlzc2luZyBibG9jayBpcyAiYXBwbGljYXRpb24gbGF5ZXIgY29udmVu dGlvbiIuIFlvdSBtYXkgdXNlDQo+IHdoYXRldmVyDQo+ID4+IGRlZmluaXRpb24geW91IHdhbnQg dG8gdGVsbCB0aGUgc2VydmVyIHRvIChyZS0pc2VuZCBub3RpZmllcyB3aXRoDQo+ID4+IGJsb2Nr cywgdGhlcmUgaXMgbm8gbmVlZCBvZiB0aGF0IGlubmVyIEdFVCByZXF1ZXN0Lg0KPiA+Pg0KPiA+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4+DQo+ID4+IGJlc3QgcmVnYXJkcw0KPiA+PiBBY2hpbQ0K PiA+Pg0KPiA+PiBBbSAwOC4wNC4yMCB1bSAyMzoyMiBzY2hyaWViIG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb206DQo+ID4+PiBSZS0sDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzLCBDYXJzdGVuLg0K PiA+Pj4NCj4gPj4+IFRoaXMgd291bGQgbWVhbiB0aGF0IGxlZ2FjeSBDb0FQIGltcGxlbXMgZG8g bm90IHN1cHBvcnQgdGhlIGNvYXAtDQo+IGluLQ0KPiA+PiBjb2FwIHByb3Bvc2FsIHdpdGhvdXQg bW9kaWZpY2F0aW9uIChnaXZlbiB0aGF0IHJmYzgxMzIgc3VwcG9ydCB3aWxsDQo+IGJlDQo+ID4+ IHJlcXVpcmVkKS4NCj4gPj4+DQo+ID4+PiBBY3R1YWxseSwgSSdtIHN0cnVnZ2xpbmcgdG8gdW5k ZXJzdGFuZCB3aGF0IHByb2JsZW0gaXMgc29sdmVkIGJ5DQo+ID4+IGRlZmluaW5nIHRoZSBOb25C bG9jazIgb3B0aW9uIGJ1dCB1c2UgaXQgb25seSB3aXRoIGFuIGV4dHJhIGNvYXANCj4gPj4gbGF5 ZXJpbmcuDQo+ID4+Pg0KPiA+Pj4gQ2hlZXJzLA0KPiA+Pj4gTWVkDQo+ID4+Pg0KPiA+Pj4+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+Pj4+IERlIDogQ2Fyc3RlbiBCb3JtYW5uIFtt YWlsdG86Y2Fib0B0emkub3JnXQ0KPiA+Pj4+IEVudm95w6kgOiBtZXJjcmVkaSA4IGF2cmlsIDIw MjAgMjM6MDgNCj4gPj4+PiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPj4+PiBD YyA6IEFjaGltIEtyYXVzOyBKb24gU2hhbGxvdzsgZG90c0BpZXRmLm9yZzsgY29yZUBpZXRmLm9y Zw0KPiA+Pj4+IE9iamV0IDogUmU6IFtjb3JlXSBbRG90c10gTGFyZ2UgYXN5bmNocm9ub3VzIG5v dGlmaWNhdGlvbnMgdW5kZXINCj4gPj4gRERvUzoNCj4gPj4+PiBOZXcgQkxPQ0sgT3B0aW9uPw0K PiA+Pj4+DQo+ID4+Pj4gT24gMjAyMC0wNC0wOCwgYXQgMjM6MDQsIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPg0KPiA+Pj4+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90 ZToNCj4gPj4+Pj4NCj4gPj4+Pj4gRG8gZXhpc3RpbmcgQ29BUCBpbXBsZW1lbnRhdGlvbnMgKGxp YmNvYXAsIGZvciBleGFtcGxlKSBzdXBwb3J0DQo+ID4+IEdFVHMNCj4gPj4+PiB3aXRoIGEgcGF5 bG9hZD8NCj4gPj4+Pg0KPiA+Pj4+IFRoYXQgaXMgd2hhdCBGRVRDSCBpcyBmb3IuDQo+ID4+Pj4N Cj4gPj4+PiBHcsO8w59lLCBDYXJzdGVuDQo+ID4+Pg0KPiA+DQoNCg== From nobody Thu Apr 9 01:08: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 3DCFD3A0E37; Thu, 9 Apr 2020 01:08:22 -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, 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 jaQILOS6WZ3L; Thu, 9 Apr 2020 01:08:16 -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 8C1593A0E36; Thu, 9 Apr 2020 01:08:15 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 48yYg05qk2z10HT; Thu, 9 Apr 2020 10:08:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586419692; bh=NoXThhJRDDoxF1Bi4pfBYbF4x6DhaQ2r8x+oBrctDw4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VjbRAEg5KoQu9gmyEyweZbaIz1I3qZV+WVY5KP2bq796FQ+/Q9GTpvKKGQEzfMBC9 iXsIh+6TeO4BrpahOy9gA33OkPrNAF+phcFEhxpVEZl84lMJh7k5yaPpdCb7DbICoz oHItQNUj8F6nfFf1Z5eHZwkBw6g70Hc7nOE0yb5UslZQ5bp006MPCYgt0cgZHsMed+ qWVl/djovT+zeQe4Ve6HycRgCSD9YWkMaZkPd4yXFwvoyOOqcEJhgdlgauFBge9Vwq Qk6Pt00A+oIXF9Njhe2W1+SagOLPeBjX1HnyXSBHD0RSEoKvjqXLePvNujKp+5Xbbq tJ4/nENieQaIA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 48yYg057nvzDq7N; Thu, 9 Apr 2020 10:08:12 +0200 (CEST) From: To: Carsten Bormann CC: Jon Shallow , "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDkYDdcp/rcch6EqdRvW32HfIMg== Date: Thu, 9 Apr 2020 08:08:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314921F4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@tzi.org> <787AE7BB302AE849A7480A190F8B9330314921C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314921C3@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 08:08:22 -0000 Q2Fyc3RlbiwgDQoNCkkgZm9yZ290IHRvIG1lbnRpb24gZm9yIHRoaXMgYWRkaXRpb25hbCAiZ3Vh cmQiOiBpdCBhcHBsaWVzIGZvciB0aGUgImZ1bGwiIG5vdGlmaWNhdGlvbiAobm90IGl0IGZyYWdt ZW50cykuDQoNCkNoZWVycywNCk1lZA0KDQo+IA0KPiBUaGUgcHJvYmluZy1yYXRlIHVzZWQgaW4g aWRsZSB0aW1lIG1heSBub3QgYmUgdGhlIHNhbWUgYXMgdGhlIG9uZQ0KPiB1c2luZyBkdXJpbmcg YXQgYXR0YWNrIHRpbWUuIFdlIGRvIGEgdmFsdWUgZm9yIGVhY2ggb2YgdGhlbS4NCj4gDQo+ICgz KSBpbiBhZGRpdGlvbiwgd2UgbmVnb3RpYXRlIHRoaXMgYWRkaXRpb25hbCAiZ3VhcmQiOg0KPiAN Cj4gICAgRE9UUyBhZ2VudHMgTVVTVCBOT1Qgc2VuZCBwcmUtb3Itb25nb2luZy1taXRpZ2F0aW9u IHRlbGVtZXRyeQ0KPiAgICBtZXNzYWdlcyB0byB0aGUgc2FtZSBwZWVyIG1vcmUgZnJlcXVlbnRs eSB0aGFuIG9uY2UgZXZlcnkNCj4gJ3RlbGVtZXRyeS0NCj4gICAgbm90aWZ5LWludGVydmFsJw0K DQo= From nobody Thu Apr 9 02:20: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 B8A7B3A0FAE; Thu, 9 Apr 2020 02:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ow2Ts_g4OOi4; Thu, 9 Apr 2020 02:20:08 -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 AD8B13A0FAC; Thu, 9 Apr 2020 02:20:07 -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 1jMTLt-00088T-U6; Thu, 09 Apr 2020 10:20:02 +0100 From: "Jon Shallow" To: "'Carsten Bormann'" , "'Achim Kraus'" , , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 9 Apr 2020 10:20:06 +0100 Message-ID: <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXQLOrs3hARxTHZMC0HZFVAKjGHtxAlevT3QCBQxhygLPG8JrqDvpP+A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 09:20:11 -0000 Hi Achim, Some clarifications on your excellent comments - I now understand the = thinking behind the Token usage. Please see inline Jon> Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 09 April 2020 08:02 > To: Achim Kraus; Carsten Bormann > Cc: Jon Shallow; dots@ietf.org; core@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Achim, >=20 > First, I was not looking to "make your example buggy". I was trying to > understand how this would work without requiring changes to the base > specs. Your feedback is highly appreciated and very useful. Thank you. >=20 > So far we have three approaches: >=20 > (1) The use of nonblock2 option with a "relax" of the behavior at the = server > to send the fragments with the same token and without waiting for = GETs. >=20 > (2) The use of a shim application as you suggested, which requires an > update on the server side but also on how clients on how to fill the = gaps > (use of PUT/FETCH). >=20 > (3) A DOTS specific approach to build its own chunks and signal blocks = as > part of the CBOR. These blocks are handled as atomic notifications. If = a block > is missing, the client can use GET+Query to retrieve the gap. We don't > require any modification at the base CoAP specs. The issue with this = one is > to decide what data to put in the blocks to avoid that when a block is = passed > to other layers, the overheads won't lead to fragmentation. >=20 > It seems to me that (2) is a little bit more complex vs (1). >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Achim Kraus [mailto:achimkraus@gmx.net] > > Envoy=C3=A9 : jeudi 9 avril 2020 08:00 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN; Carsten Bormann > > Cc : Jon Shallow; dots@ietf.org; core@ietf.org > > Objet : Re: [core] [Dots] Large asynchronous notifications under = DDoS: > > New BLOCK Option? > > > > Hi Med, > > > > maybe, we have a different understanding of the CoAP principles. > > > > RFC 7252: > > single request-responses are matched by their tokens, chosen by the > > client. The server must include that token in it's response and must > > not > > make assumptions about it. > > > > RFC 7641: > > single request - multiple responses are matched by their tokens, > > chosen > > by the client. The server must include that token in all responses = and > > must not make assumptions about it. > > > > RFC 7959: > > multiple request - multiple responses are used to transmit a large > > resource using the principals of RFC 7252/7641. > > RFC 7252 each single block transfer matches the single block request > > with it's single block response by a token chosen by the client. The > > server can not assume, that the tokens of several block-requests are > > related. > > RFC 7641 "single request - multiple responses" applies only to the > > head. > > the download of the left blocks doesn't reuse the token, nor is the > > server allowed, to make assumptions about the token. Jon> With the new nonblock2 option, the non-head blocks can have no = token, so no assumptions need to be made about the token. Etag however = will need to be used for association of the nonblock2 chunk with the = correct data set. > > > > =3D> you can't send the follow up blocks, because the token to do so = is > > not defined. It would have been defined by the (missing) client > > request. > > If the token of the observe is used, the server makes a assumption = and > > relate request of RFC7959, which are not related by the token. Jon> Again, by not having a token for the non-head blocks, this issue is = resolved I believe. > > > > Therefore I asked also about the usage of observer/notify. If a > > PUT/POST > > is used, then your transfer looks just pretty much as a blockwise = with > > NSTART-X. The drawback there will be the missing "blocksize" > > negotiation > > at the head. If that is acceptable, it should have a chance = comparable > > to the proposal. Jon> Yes, certainly the server can initiate a PUT/POST back to the = client (I like this outside of the box thinking). =20 Jon> However, for me this breaks the spirit of Observe in that whenever = a resource changes, all the subscribers are currently notified with a = unsolicited response - here it is using a POST/PUT instead. > > > > The NonBlock2 solution is not bad on it's own, but it disrupt the > > principals for the tokens on the server side, at least in my > > understanding. Jon> So, if the principals of Tokens is solved (by not having them!) = then this may work. Jon> On further reflection, as this sending all the blocks stuff can = also be done in the other direction, I think a better name for nonblock2 = would be block4 (server to client aka block2) and block3 (client to = server - aka block1). Bloc4 and block3 can be NON-Confirmable or = CONfirmable. ~jon > > > > = --------------------------------------------------------------------- > > > > > One clarification question: > > > > >> +--------->| GET /path/ctrl Token 0xf1 { NonBlock2 > > >> 1/0/1024 NonBlock2 2/0/1024 } > > > > > Do existing CoAP implementations (libcoap, for example) support > > GETs > > with a payload? > > > > > > I know, it looks a little unfair to point on single items of other > > example and then make buggy examples on my own :-). But I already > > admit > > "That should be not considered as "precise description of the > > application layer framing"". > > In fact, there is no outer GET required. The outer request could = also > > be > > POST. > > > > +--------->| POST /path/ctrl Token 0xf1 { GET /path > > Token cde NonBlock2 1/0/1024 NonBlock2 2/0/1024 } > > > > > > Just to mention, that this request triggers the notifies with the > > missing block is "application layer convention". You may use = whatever > > definition you want to tell the server to (re-)send notifies with > > blocks, there is no need of that inner GET request. > > > > = --------------------------------------------------------------------- > > > > best regards > > Achim > > > > Am 08.04.20 um 23:22 schrieb mohamed.boucadair@orange.com: > > > Re-, > > > > > > Thanks, Carsten. > > > > > > This would mean that legacy CoAP implems do not support the = coap-in- > > coap proposal without modification (given that rfc8132 support will = be > > required). > > > > > > Actually, I'm struggling to understand what problem is solved by > > defining the NonBlock2 option but use it only with an extra coap > > layering. > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De : Carsten Bormann [mailto:cabo@tzi.org] > > >> Envoy=C3=A9 : mercredi 8 avril 2020 23:08 > > >> =C3=80 : BOUCADAIR Mohamed TGI/OLN > > >> Cc : Achim Kraus; Jon Shallow; dots@ietf.org; core@ietf.org > > >> Objet : Re: [core] [Dots] Large asynchronous notifications under > > DDoS: > > >> New BLOCK Option? > > >> > > >> On 2020-04-08, at 23:04, > > >> wrote: > > >>> > > >>> Do existing CoAP implementations (libcoap, for example) support > > GETs > > >> with a payload? > > >> > > >> That is what FETCH is for. > > >> > > >> Gr=C3=BC=C3=9Fe, Carsten > > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 9 02:22: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 AD10A3A0FB6; Thu, 9 Apr 2020 02:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oc9HzllJnB1E; Thu, 9 Apr 2020 02:22:54 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185483A0FB5; Thu, 9 Apr 2020 02:22:53 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48ybK10j9vzyYS; Thu, 9 Apr 2020 11:22:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com> Date: Thu, 9 Apr 2020 11:22:31 +0200 Cc: Achim Kraus , mohamed.boucadair@orange.com, dots@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 608116951.604045-191c8906a493be5ea52de83081edf7c9 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF651E2-A6FE-43C7-A5D5-660D4CC92ED4@tzi.org> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com> To: Jon Shallow X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 09:22:57 -0000 On 2020-04-09, at 11:20, Jon Shallow wrote: >=20 > With the new nonblock2 option, the non-head blocks can have no token CoAP messages always have a token. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 9 02:27:04 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 454273A0FCE; Thu, 9 Apr 2020 02:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p5LYk2swm3E6; Thu, 9 Apr 2020 02:26:55 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFED93A0FCD; Thu, 9 Apr 2020 02:26:55 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48ybPd16jTzyYS; Thu, 9 Apr 2020 11:26:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314921C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 9 Apr 2020 11:26:35 +0200 Cc: Achim Kraus , Jon Shallow , "dots@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 608117195.143019-d9284ae29cda676ad60c2c4dafe2b9ce Content-Transfer-Encoding: quoted-printable Message-Id: <9B3883A4-9662-4E04-8FC3-00864928E801@tzi.org> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@tzi.org> <787AE7BB302AE849A7480A190F8B9330314921C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 09:26:58 -0000 Hi Med, thank you for updating me on this information! On 2020-04-09, at 09:56, = wrote: >=20 >> (b) the semantics of observe is that a notification is the whole new >> state of the resource. Proxies will implement it that way. Of = course >> block2 modifies this semantics a bit, so nonblock2 might do that too. >> Still, I think we need to consider what proxies (or client caches) >> will make out of the mechanism we devise. >=20 > [Med] Agree for the generic CoAP case.=20 >=20 > For the particular case of DOTS, sessions are established hop-by-hp = when a proxy (we called it, gateway) is involved. We have the full = visibility on what happens. =20 So you have application-aware proxies (which may not even be CoAP = proxies). But that doesn=E2=80=99t mean other proxies aren=E2=80=99t involved; = there is also the matter of client caches, which have similar properties = (caching, but no multiplexing). So far, we have tried to keep the = proxy/client-caching concept valid with extensions on CoAP; this would = be the first one where we would have to say =E2=80=9Cno CoAP proxies can = be used=E2=80=9D. I was wondering whether we can avoid this situation = (can =3D don=E2=80=99t make the solution too complex). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 9 02:27:40 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 7F8F53A0FCE; Thu, 9 Apr 2020 02:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GpbLWAwyVYQZ; Thu, 9 Apr 2020 02:27:33 -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 BA71C3A0FCD; Thu, 9 Apr 2020 02:27:32 -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 1jMTT7-00089A-KX; Thu, 09 Apr 2020 10:27:29 +0100 From: "Jon Shallow" To: "'Carsten Bormann'" , "'Achim Kraus'" , , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com> <7CF651E2-A6FE-43C7-A5D5-660D4CC92ED4@tzi.or g> In-Reply-To: <7CF651E2-A6FE-43C7-A5D5-660D4CC92ED4@tzi.org> Date: Thu, 9 Apr 2020 10:27:34 +0100 Message-ID: <031401d60e51$19baca20$4d305e60$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXQLOrs3hARxTHZMC0HZFVAKjGHtxAlevT3QCBQxhygLPG8JrAeUsamIBz/HGc6geUOaA Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 09:27:35 -0000 Hi Carsten, I stand corrected - a token with 0 length. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Carsten = Bormann > Sent: 09 April 2020 10:23 > To: Jon Shallow > Cc: mohamed.boucadair@orange.com; dots@ietf.org; core@ietf.org; Achim > Kraus > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > On 2020-04-09, at 11:20, Jon Shallow = wrote: > > > > With the new nonblock2 option, the non-head blocks can have no token >=20 > CoAP messages always have a token. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 9 04:02: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 48DE63A079E; Thu, 9 Apr 2020 04:02:41 -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 (1024-bit key) header.d=gmx.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 mEsKI7Ya9AQ9; Thu, 9 Apr 2020 04:02:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 EE64F3A079D; Thu, 9 Apr 2020 04:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586430146; bh=h1P50Hvtv9ADJsSJ/VxXUDORZDMBOHalIDCxrMeJZUU=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=YBhrsOAXUQ/4xkOdXfyEHojUs2haA5vryqLV3jKGLJLJLFYgwXfsjxt0xw2kZsY8I d8reproSYuj+zj3NAcylHrpnxTw6sek/3BL+zLSV5z/E/JgovGaMkAKu6DqrGrKUon uiLHtERBsT9rsk39eiH+wTmMyaLaIkHQ5Lqvhf1U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([94.216.236.121]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MoO2E-1iyUsk0cCu-00op0p; Thu, 09 Apr 2020 13:02:26 +0200 To: Jon Shallow , 'Carsten Bormann' , mohamed.boucadair@orange.com, dots@ietf.org, core@ietf.org References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com> <7CF651E2-A6FE-43C7-A5D5-660D4CC92ED4@tzi.org> <031401d60e51$19baca20$4d305e60$@jpshallow.com> From: Achim Kraus Message-ID: <690a94f3-d50f-c5c6-da3b-a95c2d32e756@gmx.net> Date: Thu, 9 Apr 2020 13:02:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <031401d60e51$19baca20$4d305e60$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Ze/vsvsYxT+LNNK+++9/aGvSDNXJrNqaG9nu6If64oehfJVWRSq xTLXVU59DkE3v0JuGB4hpw7NdSqT/O/Z6jOCnDAyQZdxxM7g6E72KeJ198U9haHna+hewZZ VMRxsyzB+Fo++DxiTJXqrY+Vd9a1KK9TMcseV1KDMRFocV8eiSF7Wnto+NIYdr8tFmbuQCc amITnYOvL1SmJMHWEVgBw== X-UI-Out-Filterresults: notjunk:1;V03:K0:2/x+jGJtVeI=:6LPY5eW4FaefwaZ9hLTHDl C7Sp5iX8F7az7yOb84Y5gIhTkrx4GFynIEYwCP3mFja/pRAJM/D/j5mvQk5HNIMZ3hA8SamA7 rZDZtyCnLsuyvCINjT/yhKTadRmNt+N/pG8O0UcmvMg87+9igUK1CvelbffmO/7Z4xEzt7RcV Jzz5H8RjFggWe9p/YIYNy8ghOkFC+tEdemtRz1O/WJyQQs2+6Psg2ppH5LdVGt67FYOvClhd6 HnFv6Z93S1yctxFTJKXv4Otr4n8foKgIxccYE1NseOCHm8UuUIXiLCt22K5fSpm9Ldhumrlbg BwOjLyvc/aF+VoCNffd+gm3WOu8GcwMYZKZU7YFKBpdOt/HljNzCBuW4KiK5Ymc/Hambj1Bdq /y4IoqXiEI4rgY6sFj343bZbnxRA6NsUsnix9DYFlLHk6u5rbXE6eZsP/tUMmWV4LvavPEnf5 CZMOpsfFbgUJwoFnLFXKPvmqvge7COX270feY1Lnn2/LIgLeFSn32tnKHMGQHk3PuwGMz9o+7 jhOt3nzOQuEUX/PnR4gT/6Ej1UDvwWDSSfyvzgL/GROgJX6MkwFfKpqJZuS9yt95t4h+tn8DO frfMOszWWLPkGxzsAnRhi2Tv1k34NkUoIR/4illvz2otHbwySL/TvWFmnMat7ZX4kc7K3IV/I oSFtyE4WO++2rAFp6YwVo1oLBqIArKKQy+VBW4LdAZQnSFDSXxekxakAAjILqfsc757XUahZF fGGGkfxaYnRBJHcwD7qnwyMYXI96BNpu1p/wu/8zf/+9yYIIPT93bEFzgDpuB3khWW9p+95NX /WPdyWRFQXgXNpzbLxe+lfC4pYmTIbHo4tXL1dceaYFxZC6qKt9G4eAC6V7fzvOPktEyvIJTW v5vknbL6zPLDp7LKStdlt1+QRoByXuWJzVtp0fSli14TaaNnRSFGnWl+LKuoiaQMnTcwHFtHZ GlWxJ0IOuFJJkmzifDDfEzJ5gqqYgvGItVDcqLhuwi0p4FEAoTkPlzR4kz7RiOPCU0TBcIG5N v8G75wpcz1gy1dJfGiQlJE+q3zUnEowezY7tVZ+H9DsOWIMgpL2jvqKSu97rGT8P/5OfoC23i gILdzulKXIy02Avu3aUvmjAhhOyU16i7GWImbD7R3MjjzAQsQukX9fY65xlimYznn1JkM1Cwj eu0FEr9m6KJyJ4x4ng7gvZO+SGCo3zf04vrLJJtjdDafuZh9yHow7k8/cgnMzuH6rosoqa2ga ptwRU6EFfBqGW4+x3 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 11:02:41 -0000 Hi Jon, Hi Med, > (1) The use of nonblock2 option with a "relax" of the behavior at the server to send the fragments with the same token and without waiting for GETs. The point will be, how this relaxation actually looks like. FMPOV, the hard thing will be: The server MUST not make assumptions about the token, except that it is copied from the clients request into the response. Currently the followup blocks considered to have a empty token (Jon's last note). That will hit any pending client requests with such a empty token. The matching is considered to be done via the etag. But RFC 7252 defines the etag with: "An entity-tag is intended for use as a resource-local identifier". Though it's an resource local identifier, in my opinion, you can't use that to relate your blocks. The right blocks may have that etag, but others responses may have it as well (therefore "resource-local identifier"). So, in my opinion, to know, to which resource the etags belongs to, the related request is required. Usually matched by the token, but that token is missing, because the client's request is missing. best regards Achim Am 09.04.20 um 11:27 schrieb Jon Shallow: > Hi Carsten, > > I stand corrected - a token with 0 length. > > Regards > > Jon > >> -----Original Message----- >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Carsten Bormann >> Sent: 09 April 2020 10:23 >> To: Jon Shallow >> Cc: mohamed.boucadair@orange.com; dots@ietf.org; core@ietf.org; Achim >> Kraus >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: >> New BLOCK Option? >> >> On 2020-04-09, at 11:20, Jon Shallow wrote: >>> >>> With the new nonblock2 option, the non-head blocks can have no token >> >> CoAP messages always have a token. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > From nobody Thu Apr 9 04:26: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 168CB3A0878; Thu, 9 Apr 2020 04:26: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, 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 yYXCYuuNuvr7; Thu, 9 Apr 2020 04:26:10 -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 9F1243A0873; Thu, 9 Apr 2020 04:26:09 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 48yf3M6Qbwz7trf; Thu, 9 Apr 2020 13:26:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586431567; bh=gu9+tMqXpZbTqRYxt5n/LCfz6WnW61OC3B9F54tv5bU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GBBNtw2ZZ0Q1aS9FrBOrSvRUZjYKi/KSLQEYmBxcDql7BxE78ubR+cVK8CpMKPPUT MRslqZu5cRA2SLm8gp9hbQ4gKWBAPxui6I9f0WwE5R9qFTyb+uDIbgz0k0PxvxmjnS OnDig0PmCgydzJI6l4JUBxf3WcmDrnY84dXeZlHHFqi77o6XsTtFGYeMrB7E+vJd43 WjQ8K0mRyvtLcEZPFo3VmgozDPBiY8fnUEQOLLyyWx9ibo158SpKSuqrythplPx/tP MdUSvVZl9fCp+o00yUflR/Sh+00BhGSYDX5BBp1v9/99C7R2vOv95dDEXvd/OOnfpU NblJhIsLECXew== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 48yf3M59qtz3wbY; Thu, 9 Apr 2020 13:26:07 +0200 (CEST) From: To: Carsten Bormann CC: Achim Kraus , Jon Shallow , "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDmGp8pB8W/bxlka28WEpcZ+N6A== Date: Thu, 9 Apr 2020 11:26:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149236D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <90B0B5F4-1F31-4AE7-9754-6A653AEFB6B6@tzi.org> <787AE7BB302AE849A7480A190F8B9330314921C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <9B3883A4-9662-4E04-8FC3-00864928E801@tzi.org> In-Reply-To: <9B3883A4-9662-4E04-8FC3-00864928E801@tzi.org> 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] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 11:26:11 -0000 UmUsDQoNCigxKQ0KDQpXZSBkb24ndCBoYXZlIGFuIGlzc3VlIHdpdGggb3RoZXIgQ29BUCBwcm94 aWVzIGFzIHdlIHVzZSBhIGRpc3RpbmN0IHBvcnQgbnVtYmVyIGZvciBET1RTLg0KDQooMikNCg0K Rm9yIHRoZSBwdXJlIENvQVAgY2FzZSwgdGhlIG5ld0Jsb2NrIG9wdGlvbnMgd2lsbCBiZSBtYXJr ZWQgYXMgY3JpdGljYWwgYW5kIHVuc2FmZSB0byBmb3J3YXJkLiBUaGVyZSBpcyBubyBjYWNoaW5n IGlzc3VlIGZvciBhIHByb3h5IHRoYXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgb3B0aW9uLiBH RVQgd2l0aCB0aGlzIG9wdGlvbiB3aWxsIGJlIHJlamVjdGVkIGJ5IHRoZSBwcm94eS4gVGhlIHNl cnZlciB3aWxsIHJlamVjdCByZXF1ZXN0cyB3aXRoIHRoZSBuZXdCbG9jayBpZiBpdCBkb2VzIG5v dCB1bmRlcnN0YW5kIGl0LiBUaGlzIGlzIHNpbXBsZS4gDQoNCkZvciBhIHByb3h5IHRoYXQgc3Vw cG9ydHMgYmxvY2sgb3B0aW9ucywgdGhlIGJsb2Nrd2lzZSBzcGVjIGRvZXMgbm90IGltcG9zZSB0 byBoYXZlIGFsbCBmcmFnbWVudHMuIFRoZSBzcGVjIGxlYXZlcyBpdCBvcGVuIHRvIGltcGxlbWVu dGF0aW9uczogaWYgd2UgZG9uJ3QgaGF2ZSBhIGxvc3MsIGFsbCBmcmFnbWVudHMgd2lsbCBiZSBw cmVzZW50LiBUaGUgcHJveHkgY2FuIGJlIHNlcnZlIGNsaWVudHMgd2l0aCBpbmRpdmlkdWFsIGJs b2Nrcy4gDQoNCldlIHdvbid0IHJlcXVpcmUgYWxsIGZyYWdtZW50cyB0byBiZSByZWFzc2VtYmxl ZCBhdCB0aGUgcHJveHkuIFdlIGp1c3QgbmVlZCBpbmRpdmlkdWFsIGJsb2Nrcy4gRm9yIGV4YW1w bGUsIGlmIHRoZSBjbGllbnQtcHJveHkgbGVnIGlzIGxvc3N5LCB0aGUgcHJveHkgY2FuIHNlcnZl IGltbWVkaWF0ZWx5IHRoZSBjbGllbnQgd2l0aCBtaXNzaW5nIGJsb2Nrcy4gVGhpcyB3aWxsIGJl IHBhcnQgb2YgdGhlIG5ldyBiZWhhdmlvciAod2hpY2ggaXMgZmluZSBnaXZlbiB0aGF0IHRoZXNl IHByb3hpZXMgYXJlIGFzc3VtZWQgdG8gc3VwcG9ydCB0aGUgb3B0aW9uKS4NCg0KQ2xpZW50cyBj YW4gZGV0ZXJtaW5lIHRoZSBpbml0aWFsIGJsb2NrIHNpemUgaW4gaW5pdGlhbCBuZXdCbG9jay4g SWYgdGhlIHNlcnZlciBkb2VzIG5vdCBsaWtlIGl0IGFuZCB3YW50cyB0byBzZW5kIGJhY2sgYSBy ZWR1Y2VkIHNpemUsIHRoYXQgd291bGQgYmUgZmluZSBhbmQgdGhlIGNsaWVudCB3b3VsZCBzZWUg b25lIG9mIHRoZSBuZXdCbG9jayB3aXRoIHNtYWxsZXIgc2l6ZSBhbmQga25vdyB0byBhc2sgZm9y IHRoZSBzbWFsbGVyIHNpemVzLiANCg0KSSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gZnVydGhlciBh c3Nlc3MgdGhpcyBjYXJlZnVsbHkgYnV0IHdlIGFyZSBub3Qgc3VyZSB5ZXQgdGhlcmUgaXMgYW4g aXNzdWUgd2l0aCByZWdhcmRzIHRvIGNhY2hpbmcuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpj YWJvQHR6aS5vcmddDQo+IEVudm95w6nCoDogamV1ZGkgOSBhdnJpbCAyMDIwIDExOjI3DQo+IMOA wqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gQ2PCoDogQWNoaW0gS3JhdXM7IEpvbiBT aGFsbG93OyBkb3RzQGlldGYub3JnOyBjb3JlQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbY29y ZV0gW0RvdHNdIExhcmdlIGFzeW5jaHJvbm91cyBub3RpZmljYXRpb25zIHVuZGVyIEREb1M6DQo+ IE5ldyBCTE9DSyBPcHRpb24/DQo+IA0KPiBIaSBNZWQsDQo+IA0KPiB0aGFuayB5b3UgZm9yIHVw ZGF0aW5nIG1lIG9uIHRoaXMgaW5mb3JtYXRpb24hDQo+IA0KPiBPbiAyMDIwLTA0LTA5LCBhdCAw OTo1NiwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPg0KPiA+PiAoYikgdGhlIHNlbWFudGljcyBvZiBvYnNl cnZlIGlzIHRoYXQgYSBub3RpZmljYXRpb24gaXMgdGhlIHdob2xlDQo+IG5ldw0KPiA+PiBzdGF0 ZSBvZiB0aGUgcmVzb3VyY2UuICBQcm94aWVzIHdpbGwgaW1wbGVtZW50IGl0IHRoYXQgd2F5LiAg T2YNCj4gY291cnNlDQo+ID4+IGJsb2NrMiBtb2RpZmllcyB0aGlzIHNlbWFudGljcyBhIGJpdCwg c28gbm9uYmxvY2syIG1pZ2h0IGRvIHRoYXQNCj4gdG9vLg0KPiA+PiBTdGlsbCwgSSB0aGluayB3 ZSBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgcHJveGllcyAob3IgY2xpZW50IGNhY2hlcykNCj4gPj4g d2lsbCBtYWtlIG91dCBvZiB0aGUgbWVjaGFuaXNtIHdlIGRldmlzZS4NCj4gPg0KPiA+IFtNZWRd IEFncmVlIGZvciB0aGUgZ2VuZXJpYyBDb0FQIGNhc2UuDQo+ID4NCj4gPiBGb3IgdGhlIHBhcnRp Y3VsYXIgY2FzZSBvZiBET1RTLCBzZXNzaW9ucyBhcmUgZXN0YWJsaXNoZWQgaG9wLWJ5LWhwDQo+ IHdoZW4gYSBwcm94eSAod2UgY2FsbGVkIGl0LCBnYXRld2F5KSBpcyBpbnZvbHZlZC4gV2UgaGF2 ZSB0aGUgZnVsbA0KPiB2aXNpYmlsaXR5IG9uIHdoYXQgaGFwcGVucy4NCj4gDQo+IFNvIHlvdSBo YXZlIGFwcGxpY2F0aW9uLWF3YXJlIHByb3hpZXMgKHdoaWNoIG1heSBub3QgZXZlbiBiZSBDb0FQ DQo+IHByb3hpZXMpLg0KPiANCj4gQnV0IHRoYXQgZG9lc27igJl0IG1lYW4gb3RoZXIgcHJveGll cyBhcmVu4oCZdCBpbnZvbHZlZDsgdGhlcmUgaXMgYWxzbyB0aGUNCj4gbWF0dGVyIG9mIGNsaWVu dCBjYWNoZXMsIHdoaWNoIGhhdmUgc2ltaWxhciBwcm9wZXJ0aWVzIChjYWNoaW5nLCBidXQNCj4g bm8gbXVsdGlwbGV4aW5nKS4gIFNvIGZhciwgd2UgaGF2ZSB0cmllZCB0byBrZWVwIHRoZSBwcm94 eS9jbGllbnQtDQo+IGNhY2hpbmcgY29uY2VwdCB2YWxpZCB3aXRoIGV4dGVuc2lvbnMgb24gQ29B UDsgdGhpcyB3b3VsZCBiZSB0aGUgZmlyc3QNCj4gb25lIHdoZXJlIHdlIHdvdWxkIGhhdmUgdG8g c2F5IOKAnG5vIENvQVAgcHJveGllcyBjYW4gYmUgdXNlZOKAnS4gIEkgd2FzDQo+IHdvbmRlcmlu ZyB3aGV0aGVyIHdlIGNhbiBhdm9pZCB0aGlzIHNpdHVhdGlvbiAoY2FuID0gZG9u4oCZdCBtYWtl IHRoZQ0KPiBzb2x1dGlvbiB0b28gY29tcGxleCkuDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQoN Cg== From nobody Thu Apr 9 04: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 5DF2F3A0873; Thu, 9 Apr 2020 04:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aZ7PmeWvDlA9; Thu, 9 Apr 2020 04:27:16 -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 0A4A83A086C; Thu, 9 Apr 2020 04:27:15 -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 1jMVKy-0008Dd-LV; Thu, 09 Apr 2020 12:27:12 +0100 From: "Jon Shallow" To: "'Achim Kraus'" , "'Carsten Bormann'" , , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <023101d60d92$3642ebb0$a2c8c310$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031491DA6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1A59D5BE-8826-45FE-B373-CF335831B3A4@tzi.org> <787AE7BB302AE849A7480A190F8B933031491E13@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2bd7cba1-7ab7-f028-aa96-6d654c7ffed4@gmx.net> <787AE7BB302AE849A7480A190F8B93303149212D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031201d60e50$0ee1a610$2ca4f230$@jpshallow.com> <7CF651E2-A6FE-43C7-A5D5-660D4CC92ED4@tzi.org> <031401d60e51$19baca20$4d305e60$@jpshallow.com> <690a94f3-d50f-c5c6-da3b-a95c2d32e756@gmx.net> In-Reply-To: <690a94f3-d50f-c5c6-da3b-a95c2d32e756@gmx.net> Date: Thu, 9 Apr 2020 12:27:17 +0100 Message-ID: <032401d60e61$d31a48a0$794ed9e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwJH0mmYAXSXKBYCBDJ5uAHQ6UBdAs6uzeEBHFMdkwLQdkVUAqMYe3ECV69PdAIFDGHKAs8bwmsB5SxqYgHP8cZzAhrr978B1E28kKgUGb2w Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 09 Apr 2020 11:27:19 -0000 Hi Achim, I hear you. How about extending the NonBLock2 option to contain more information. = E.g.=20 o the size of the block (SZX); o whether more blocks are following (M); o the relative number of the block (NUM) within a sequence of blocks with the given size. o the block set id (like the IPv4 fragment id field) for = re-assembly. Thus making the nonblock2 option length 0 to, say, 7 bytes long.=20 Regards Jon=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus > Sent: 09 April 2020 12:02 > To: Jon Shallow; 'Carsten Bormann'; mohamed.boucadair@orange.com; > dots@ietf.org; core@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Jon, > Hi Med, >=20 > > (1) The use of nonblock2 option with a "relax" of the behavior at = the > server to send the fragments with the same token and without waiting = for > GETs. >=20 > The point will be, how this relaxation actually looks like. > FMPOV, the hard thing will be: > The server MUST not make assumptions about the token, except that it = is > copied from the clients request into the response. >=20 > Currently the followup blocks considered to have a empty token (Jon's > last note). That will hit any pending client requests with such a = empty > token. The matching is considered to be done via the etag. But RFC = 7252 > defines the etag with: > "An entity-tag is intended for use as a resource-local identifier". > Though it's an resource local identifier, in my opinion, you can't use > that to relate your blocks. The right blocks may have that etag, but > others responses may have it as well (therefore "resource-local > identifier"). > So, in my opinion, to know, to which resource the etags belongs to, = the > related request is required. Usually matched by the token, but that > token is missing, because the client's request is missing. >=20 >=20 > best regards > Achim >=20 > Am 09.04.20 um 11:27 schrieb Jon Shallow: > > Hi Carsten, > > > > I stand corrected - a token with 0 length. > > > > Regards > > > > Jon > > > >> -----Original Message----- > >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Carsten > Bormann > >> Sent: 09 April 2020 10:23 > >> To: Jon Shallow > >> Cc: mohamed.boucadair@orange.com; dots@ietf.org; core@ietf.org; > Achim > >> Kraus > >> Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > >> New BLOCK Option? > >> > >> On 2020-04-09, at 11:20, Jon Shallow = wrote: > >>> > >>> With the new nonblock2 option, the non-head blocks can have no = token > >> > >> CoAP messages always have a token. > >> > >> Gr=C3=BC=C3=9Fe, Carsten > >> > >> _______________________________________________ > >> Dots mailing list > >> Dots@ietf.org > >> https://www.ietf.org/mailman/listinfo/dots > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 9 06:42:20 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 3EAE63A0B58; Thu, 9 Apr 2020 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_LOW=-0.7, 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 t2On1DXXx2Mt; Thu, 9 Apr 2020 06:42:14 -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 899293A0B67; Thu, 9 Apr 2020 06:42:10 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 48yj4J6tQlz2xlx; Thu, 9 Apr 2020 15:42:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586439729; bh=BHrrI1P+TbqUHebKS5HgC37l4U7HwPJuvOE5yWznXfY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=t5HFa7v0ZKVmsCcQQ7kTOu8tef4uJJcE5llh92sYgXDyNDh9LI+miDW8UdWbCsHA3 +CoWN/ao+q2rvcjihnTR6fOZBT02b6pLf5B6xZ+BF61LwNtOWOQXOqnP3nWf5VbBRT qQYy/u+7Sx/ezMNMz2TQI+/xyHOPLUqHC7rVaOREHdFlc3uGUgcAyQdfqKepUlBAig MG05TsAXNwzsPuQOI+tUWvH+/Cw8yzBkqKDnVH9eBQXx+j7WsnkD5HaMh66mg2ph0B GXkva1na1ASuc1udQzvSXELc7xumcL7glZi/3dtRugXlBRMO1FRRdO2iLRD7dH6JvB rBq/VBqBSEi+g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 48yj4J5v0Sz1xpv; Thu, 9 Apr 2020 15:42:08 +0200 (CEST) From: To: "core@ietf.org" CC: "dots@ietf.org" Thread-Topic: [core] [Technical Errata Reported] RFC7252 (5284) Thread-Index: AQHTt4ndJXGy2My7rUmHIFbO9dEyFKPPl8uAhKXgpcA= Date: Thu, 9 Apr 2020 13:42:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149256F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20180309093425.91095B81706@rfc-editor.org> <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com> In-Reply-To: <3bf7a04492be4f4c882e344cafd4e188@bosch-si.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] [core] [Technical Errata Reported] RFC7252 (5284) 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, 09 Apr 2020 13:42:20 -0000 Hi all, I lost the context about the resolution for this errata. Any update on this= one? Thank you.=20 Cheers, Med > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of RFC Errata > System > Sent: Freitag, 9. M=E4rz 2018 10:34 > To: zach.shelby@arm.com; hartke@tzi.org; cabo@tzi.org; > ben@nostrum.com; aamelnikov@fastmail.fm; adam@nostrum.com; > cabo@tzi.org; jaime@iki.fi > Cc: mohamed.boucadair@orange.com; core@ietf.org; rfc-editor@rfc- > editor.org > Subject: [core] [Technical Errata Reported] RFC7252 (5284) >=20 > The following errata report has been submitted for RFC7252, "The > Constrained Application Protocol (CoAP)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5284 >=20 > -------------------------------------- > Type: Technical > Reported by: Mohamed Boucadair >=20 > Section: 5.3.1 >=20 > Original Text > ------------- > The client SHOULD generate tokens in such a way that tokens currently > in use for a given source/destination endpoint pair are unique. >=20 > Corrected Text > -------------- > The client SHOULD generate tokens in such a way that tokens currently > in use for a given source/destination endpoint pair are unique per > request. >=20 > Notes > ----- > Multiple requests may be active for a given source/destination > endpoint pair. The OLD text is thus broken. >=20 > The NEW text is aligned with the definition of the Token: >=20 > A token is intended for use as a client-local identifier for > differentiating between concurrent requests (see Section 5.3); it > could have been called a "request ID". >=20 > Further, using the same token for a given source/destination endpoint > pair have some implications, for example, for applications which > require the support of multiple observe queries because RFC7641 states > the following: >=20 > The entry in the list of observers is keyed by the client endpoint > and the token specified by the client in the request. If an entry > with a matching endpoint/token pair is already present in the list > (which, for example, happens when the client wishes to reinforce > its interest in a resource), the server MUST NOT add a new entry > but MUST replace or update the existing one. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or rejected. > When a decision is reached, the verifying party can log in to change > the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC7252 (draft-ietf-core-coap-18) > -------------------------------------- > Title : The Constrained Application Protocol (CoAP) > Publication Date : June 2014 > Author(s) : Z. Shelby, K. Hartke, C. Bormann > Category : PROPOSED STANDARD > Source : Constrained RESTful Environments APP > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Apr 12 16:33:20 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 C43233A0C9B for ; Sun, 12 Apr 2020 16:33:18 -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 fpvepxTZVoAO for ; Sun, 12 Apr 2020 16:33:16 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A33A0C9A for ; Sun, 12 Apr 2020 16:33:14 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee65e93a528c84-25cb3; Mon, 13 Apr 2020 07:33:00 +0800 (CST) X-RM-TRANSID: 2ee65e93a528c84-25cb3 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[120.244.166.72]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee45e93a52bc52-84ea0; Mon, 13 Apr 2020 07:32:59 +0800 (CST) X-RM-TRANSID: 2ee45e93a52bc52-84ea0 Date: Mon, 13 Apr 2020 07:33:02 +0800 From: "Meiling Chen" To: mohamed.boucadair , dots References: <158624600381.27398.18200958068747513105@ietfa.amsl.com>, <787AE7BB302AE849A7480A190F8B93303148FF3D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.115[cn] Mime-Version: 1.0 Message-ID: <2020041307330224403520@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart753647627284_=----" Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-06.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: Sun, 12 Apr 2020 23:33:19 -0000 This is a multi-part message in MIME format. ------=_001_NextPart753647627284_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KSSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQsICBhbmQgSSBoYXZlIHNvbWUgcXVl c3Rpb25zOg0KMS4gc2VjdGlvbiA3IGNvbnRhaW5zIHByZS1vci1vbmdvaW5nIG1pdGlnYXRpb24g dGVsZW1ldHJ5LCB3aHkgbm90IHRoZSB0ZWxlbWV0cnkgYWZ0ZXIgdGhlIGVuZCBvZiBtaXRpZ2F0 aW9uLg0KMi5UZWxlbWV0cnkgcHV0IHJlcXVlc3Qgc2VudCBhZnRlciBhIG1pdGlnYXRpb24gcmVx dWVzdCwgaXMgdGhhdCBtZWFucyB0ZWxlbWV0cnkgcmVxdWVzdCBhbmQgbWl0aWdhdGlvbiByZXF1 ZXN0IHdpbGwgbm90IGJlIGluIG9uZSBwYWNrZXQ/DQozLiJhdHRhY2stc2V2ZXJpdHkiIGhhcyB0 aHJlZSBvcHRpb25zLCBob3cgdG8gZGV0ZXJtaW5lIHdoaWNoIGxldmVsIHRoZSBhdHRhY2sgaXM/ DQo0LkZvciAidG9wLXRhbGtlcnMiLCBpcyBpdCBuZWNlc3NhcnkgdG8gc3BlY2lmeSB0aGUgcXVh bnRpdHk/DQogDQpGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQpEYXRlOiAyMDIw LTA0LTA3IDE2OjAzDQpUbzogZG90c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEb3RzXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTA2LnR4dA0KSGkgYWxsLCANCiANClRo ZSBtYWluIGNoYW5nZXMgaW4gdGhpcyB2ZXJzaW9uIGFyZSBhcyBmb2xsb3dzOg0KKiBhZGQgYSBy ZW1pbmRlciB0aGF0IGN1aWQvY2RpZCBtdXN0IG5vdCBhcHBlYXIgaW4gdGhlIG1lc3NhZ2UgYm9k eQ0KKiBhZGQgYSByZW1pbmRlciBhYm91dCB0aGUgdXNlIG9mIFlBTkcNCiogYWRkIGEgY2xhcmlm aWNhdGlvbiBhYm91dCByZWZyZXNoIG9mIHRlbGVtZXRyeSBjb25maWd1cmF0aW9uDQoqIFJlc3Ry dWN0dXJlIHRoZSBtb2RlbCB0byBmaXggYSBwcm9ibGVtIHJhaXNlZCBieSBKb24gYWJvdXQgYWNj ZXNzIHRvIG1heC9taW4gZGF0YSB3aGVuIG5vIHRzaWQgaXMgaW4gcGxhY2UuDQoqIERlZmluZSB1 bml0LXR5cGUgDQoqIGF0dGFjayBkZXRhaWxzIGFyZSBub3QgbW9kZWxlZCBhcyBhbiBhcnJheQ0K KiBhZGQgbmV3IGNvbnRhaW5lcnMgdG9uIGNvbnZleSBwcm90b2NvbC0gYW5kIHBvcnQtc3BlY2lm aWMgdGVsZW1ldHJ5IGRhdGEuIA0KKiBhZGQgYSBjbGFyaWZpY2F0aW9uIGFib3V0IHBhcnRpYWwg cmVxdWVzdHMNCiogYWRkIGEgY2xhcmlmaWNhdGlvbiBhYm91dCB0aGUgdXNhZ2Ugb2YgcGVyIHBy b3RvY29sIGFuZCBwZXItcG9ydCBtZXRyaWNzLiANCiogdGVsZW1ldHJ5IGRhdGEgY2FuIG5vdyBi ZSBmaWx0ZXJlZCB1c2luZyBVcmktUXVlcnkgb3B0aW9ucw0KKiBhZGQgYSBub3RlIGFib3V0IGhh bmRsaW5nIGJhc2VsaW5lIHRvIGFjY29tbW9kYXRlIG5vbi1hdHRhY2sgb3ZlcmxvYWRzDQoqIGRl c2NyaWJlIGhvdyB0byBkZWxldGUgInRtaWRzJw0KKiB1cGRhdGUgdGhlIGNib3IvbWFwcGluZyB0 YWJsZXMuIA0KIA0KVGhlIHBvaW50IGFib3V0IGxvbmcgcmVzcG9uc2VzIGlzIHN0aWxsIFBFTkRJ TkcuICANCiANClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMuDQogDQpDaGVl cnMsDQpNZWQNCiANCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogSS1ELUFu bm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQg ZGUNCj4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IEVudm95qKYgOiBtYXJkaSA3IGF2cmls IDIwMjAgMDk6NTMNCj4gqKQgOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gQ2MgOiBkb3RzQGll dGYub3JnDQo+IE9iamV0IDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS0w Ni50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFdHIG9mIHRo ZQ0KPiBJRVRGLg0KPiANCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBEaXN0cmlidXRlZCBE ZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdA0KPiBTaWduYWxpbmcgKERPVFMpIFRlbGVtZXRy eQ0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWlyDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgVGlydW1hbGVzd2FyIFJlZGR5DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgRWh1ZCBEb3Jvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIE1laWxp bmcgQ2hlbg0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTA2 LnR4dA0KPiBQYWdlcyAgICAgICAgICAgOiA5Mw0KPiBEYXRlICAgICAgICAgICAgOiAyMDIwLTA0 LTA3DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBhaW1zIHRvIGVucmljaCBE T1RTIHNpZ25hbCBjaGFubmVsIHByb3RvY29sIHdpdGgNCj4gICAgdmFyaW91cyB0ZWxlbWV0cnkg YXR0cmlidXRlcyBhbGxvd2luZyBvcHRpbWFsIEREb1MgYXR0YWNrDQo+IG1pdGlnYXRpb24uDQo+ ICAgIEl0IHNwZWNpZmllcyB0aGUgbm9ybWFsIHRyYWZmaWMgYmFzZWxpbmUgYW5kIGF0dGFjayB0 cmFmZmljDQo+IHRlbGVtZXRyeQ0KPiAgICBhdHRyaWJ1dGVzIGEgRE9UUyBjbGllbnQgY2FuIGNv bnZleSB0byBpdHMgRE9UUyBzZXJ2ZXIgaW4gdGhlDQo+ICAgIG1pdGlnYXRpb24gcmVxdWVzdCwg dGhlIG1pdGlnYXRpb24gc3RhdHVzIHRlbGVtZXRyeSBhdHRyaWJ1dGVzIGENCj4gRE9UUw0KPiAg ICBzZXJ2ZXIgY2FuIGNvbW11bmljYXRlIHRvIGEgRE9UUyBjbGllbnQsIGFuZCB0aGUgbWl0aWdh dGlvbg0KPiBlZmZpY2FjeQ0KPiAgICB0ZWxlbWV0cnkgYXR0cmlidXRlcyBhIERPVFMgY2xpZW50 IGNhbiBjb21tdW5pY2F0ZSB0byBhIERPVFMNCj4gc2VydmVyLg0KPiAgICBUaGUgdGVsZW1ldHJ5 IGF0dHJpYnV0ZXMgY2FuIGFzc2lzdCB0aGUgbWl0aWdhdG9yIHRvIGNob29zZSB0aGUNCj4gRERv Uw0KPiAgICBtaXRpZ2F0aW9uIHRlY2huaXF1ZXMgYW5kIHBlcmZvcm0gb3B0aW1hbCBERG9TIGF0 dGFjayBtaXRpZ2F0aW9uLg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5Lw0KPiANCj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6 ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS0wNg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMDYNCj4gDQo+IEEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMDYNCj4gDQo+ IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcg bGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQogDQo= ------=_001_NextPart753647627284_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Hi Meiling,

 

Thank you for the review.

 

Please see inline.

 

Cheers,<= /p>

Med

 

De : Meiling Chen [mailto:chenmeiling@chinamobile.com]
Envoy=E9 : lundi 13 avril 2020 01:33
=C0 : BOUCADAIR Mohamed TGI/OLN; dots
Objet : Re: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-06= .txt

 

Hi all,<= /span>

I have reviewed thi= s draft,  and I have some questions:

1. section 7 contai= ns pre-or-ongoing mitigation telemetry, why not the telemetry after the end= of mitigation.

[Med] This is possib= le, e.g., with a status update (Section 8.1) with "status": "= ;attack-successfully-mitigated".

 =

2.Telemetry put req= uest sent after a mitigation request, is that means telemetry request and m= itigation request will not be in one packet?

[Med] Yes. This is w= hy we discuss how to bind the requests:

 

   = DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data with<= /o:p>

   = mitigation requests relying upon the target clause.  In particular, a<= o:p>

   = telemetry PUT request sent after a mitigation request may include a

   = reference to that mitigation request ('mid-list') as shown in

   = Figure 22.  An example illustrating requests correlation by means of

   = 'target-prefix' is shown in Figure 23.

 

3."attack-seve= rity" has three options, how to determine which level the attack is?

[Med] This is implem= entation-specific.  

 

4.For "top-tal= kers", is it necessary to specify the quantity?

[Med] Yuhei already = clarified this one.

 

Date: 2020-04-07 16:03<= /o:p>

Subject: Re: [Dots] I-D Action: d= raft-ietf-dots-telemetry-06.txt

Hi all,

 

The main changes in= this version are as follows:

* add a reminder th= at cuid/cdid must not appear in the message body

* add a reminder ab= out the use of YANG

* add a clarificati= on about refresh of telemetry configuration

* Restructure the m= odel to fix a problem raised by Jon about access to max/min data when no ts= id is in place.

* Define unit-type

* attack details ar= e not modeled as an array

* add new container= s ton convey protocol- and port-specific telemetry data.

* add a clarificati= on about partial requests

* add a clarificati= on about the usage of per protocol and per-port metrics.

* telemetry data ca= n now be filtered using Uri-Query options

* add a note about = handling baseline to accommodate non-attack overloads

* describe how to d= elete "tmids'

* update the cbor/m= apping tables.

 

The point about lon= g responses is still PENDING. 

 

Please review and s= hare your comments.

 

Cheers,<= /span>

Med

 

> -----Message d= 'origine-----

> De : I-D-= Announce [mailto:i-d-announce-bounces@ietf.org] De la part de

> internet-draft= s@ietf.org

> Envoy=E9 : mardi 7 avril 2020 09:53

> =E0 : i-d-announce@ietf.org

> Cc : dots= @ietf.org

> Objet : I= -D Action: draft-ietf-dots-telemetry-06.txt

>

>

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

>

>  &nb= sp;      Title      =      : Distributed Denial-of-Service Open Threat

> Signaling (DOT= S) Telemetry

>  &nb= sp;      Authors     &nbs= p;   : Mohamed Boucadair

>  &nb= sp;            =             Tirumale= swar Reddy

>  &nb= sp;            =             Ehud Dor= on

>  &nb= sp;            =             Meiling = Chen

> Filename =        : draft-ietf-dots-telemetry-06.txt

> Pages &nb= sp;         : 93<= /p>

> Date &nbs= p;          : 2020-04-07<= /o:p>

>

> Abstract:=

>  &nb= sp; This document aims to enrich DOTS signal channel protocol with

>  &nb= sp; various telemetry attributes allowing optimal DDoS attack

> mitigation.

>  &nb= sp; It specifies the normal traffic baseline and attack traffic<= /span>

> telemetry=

>  &nb= sp; attributes a DOTS client can convey to its DOTS server in the

>  &nb= sp; mitigation request, the mitigation status telemetry attributes a

> DOTS

>  &nb= sp; server can communicate to a DOTS client, and the mitigation<= /span>

> efficacy<= /o:p>

>  &nb= sp; telemetry attributes a DOTS client can communicate to a DOTS=

> server.

>  &nb= sp; The telemetry attributes can assist the mitigator to choose the

> DDoS

>  &nb= sp; mitigation techniques and perform optimal DDoS attack mitigation.<= /o:p>

>

>

> The IETF datat= racker status page for this draft is:

> https://datatr= acker.ietf.org/doc/draft-ietf-dots-telemetry/

>

> There are also= htmlized versions available at:

> https://tools.= ietf.org/html/draft-ietf-dots-telemetry-06

> https://datatr= acker.ietf.org/doc/html/draft-ietf-dots-telemetry-06

>

> A diff from th= e previous version is available at:

> https://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-06

>

>

> Please note th= at it may take a couple of minutes from the time of

> submission

> until the html= ized version and diff are available at tools.ietf.org.

>

> Internet-Draft= s are also available by anonymous FTP at:

> ftp://ftp.ietf= .org/internet-drafts/

>

>

> ______________= _________________________________

> I-D-Announce m= ailing list

> I-D-Announce@i= etf.org

> https://www.ie= tf.org/mailman/listinfo/i-d-announce

> Internet-Draft= directories: http://www.ietf.org/shadow.html

> or ftp://ftp.i= etf.org/ietf/1shadow-sites.txt

 

___________________= ____________________________

Dots mailing list

Dots@ietf.org<= /o:p>

https://www.ietf.or= g/mailman/listinfo/dots

 

--_000_787AE7BB302AE849A7480A190F8B933031494CC5OPEXCAUBMA2corp_-- From nobody Tue Apr 14 06:30:53 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 B18FD3A0E82 for ; Tue, 14 Apr 2020 06:30:51 -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, 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 QXpbKuhjY8m4 for ; Tue, 14 Apr 2020 06:30:50 -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 3BBCF3A0E7F for ; Tue, 14 Apr 2020 06:30:50 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 491mZw1zq9z5vfZ for ; Tue, 14 Apr 2020 15:30:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586871048; bh=9SwuFS+HyLrT14Rnj4gNUbArni+aC7v66jddma1ZbCc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=qs8u9SBYmnV4DB4n+YEEVofCeLtztftbikp8yh4SZEt34bL8a2CASWv+cKVgwvN1Z NKKt3eIDqlTqkFV1HORf0F9N8/q76kulFekxGEdr+sCZ+ckWamegTK2yb7dyooHgyd uVEMrts6jEY/VHKVN1zIAxjh7/GGyf1fzvfLz6mQShMYa8PdPWXVJA6xAf9jm6jmln eo5/fzlRAF8M9T30Ygzq3SSW/p/dM3AI5DzflUc9nvXSbuZujLUihPIpCMYapk8C5+ IGLSMK537LobWtZSQgiTlCXoHJGJtPUaRqqsDRHsWaK8LGXqxmHveKFj3TUV+XBOiO oRByKlM6d6CjQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 491mZw1Fy4zDq78 for ; Tue, 14 Apr 2020 15:30:48 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-bosh-core-new-block-00.txt Thread-Index: AQHWEl/W/Kx+LjW+NESAgd3Y+ur5Tah4m1qQgAABnnA= Date: Tue, 14 Apr 2020 13:30:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031494E0D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158687058384.18108.18222984813247786930@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933031494DF4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031494DF4@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] TR: New Version Notification for draft-bosh-core-new-block-00.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: Tue, 14 Apr 2020 13:30:52 -0000 RllJLiBNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBjb3JlIFttYWls dG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20NCkVudm95w6nCoDogbWFyZGkgMTQgYXZyaWwgMjAyMCAxNToyOQ0Kw4DCoDog Y29yZUBpZXRmLm9yZw0KT2JqZXTCoDogW2NvcmVdIFRSOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2stMDAudHh0DQoNCkhpIGFsbCwgDQoNClRo ZSBkcmFmdCBpcyBhYm91dCB0aGUgbmV3IEJsb2NrIG9wdGlvbnMgd2UgZGlzY3Vzc2VkIG9uIHRo ZSBsaXN0Lg0KDQpQbGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLiANCg0KVGhh bmsgeW91LiANCg0KQ2hlZXJzLA0KSm9uICYgTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KRGXCoDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSANCkVudm95w6nCoDogbWFyZGkgMTQgYXZyaWwgMjAyMCAxNToyMw0Kw4DC oDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgSm9uIFNoYWxsb3cNCk9iamV0wqA6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9jay0wMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9jay0wMC50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIg YW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWJvc2gt Y29yZS1uZXctYmxvY2sNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlOZXcgQ29uc3RyYWluZWQgQXBw bGljYXRpb24gUHJvdG9jb2wgKENvQVApIEJsb2NrLVdpc2UgVHJhbnNmZXIgT3B0aW9ucw0KRG9j dW1lbnQgZGF0ZToJMjAyMC0wNC0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOgkJMTgNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9jay0wMC50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3NoLWNvcmUtbmV3LWJsb2Nr Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3No LWNvcmUtbmV3LWJsb2NrLTAwDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3NoLWNvcmUtbmV3LWJsb2NrDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBuZXcgQ29uc3RyYWluZWQgQXBwbGljYXRpb24g UHJvdG9jb2wgKENvQVApDQogICBCbG9jay1XaXNlIHRyYW5zZmVyIG9wdGlvbnM6IEJsb2NrMyBh bmQgQmxvY2s0IG9wdGlvbnMuICBUaGVzZQ0KICAgb3B0aW9ucyBhcmUgc2ltaWxhciB0byB0aGUg Q29BUCBCbG9jazEgYW5kIEJsb2NrMiBvcHRpb25zLCBidXQgZW5hYmxlDQogICBmYXN0ZXIgdHJh bnNtaXNzaW9ucyBvZiBiaWcgYmxvY2tzIG9mIGRhdGEgd2l0aCBsZXNzIHBhY2tldA0KICAgaW50 ZXJjaGFuZ2VzIGFzIHdlbGwgYXMgc3VwcG9ydGluZyBmYXN0ZXIgcmVjb3Zlcnkgc2hvdWxkIGFu eSBvZiB0aGUNCiAgIEJsb2NrcyBnZXQgbG9zdCBpbiB0cmFuc21pc3Npb24uDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Wed Apr 15 12:26:17 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 93CC93A080E; Wed, 15 Apr 2020 12:25:33 -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: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158697873353.29013.4148200236781320443@ietfa.amsl.com> Date: Wed, 15 Apr 2020 12:25:33 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-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: Wed, 15 Apr 2020 19:25:34 -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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Filename : draft-ietf-dots-telemetry-07.txt Pages : 95 Date : 2020-04-15 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-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 Wed Apr 15 22:39:56 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 C76453A0E7E for ; Wed, 15 Apr 2020 22:39:53 -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, 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 BB5BZtyw8j4x for ; Wed, 15 Apr 2020 22:39:51 -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 2BB553A0E80 for ; Wed, 15 Apr 2020 22:39:48 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 492p2V0gRlz8t9g for ; Thu, 16 Apr 2020 07:39:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587015586; bh=IcllbUObrQJO2JJqq4vEtyku3z1rjar0XUgXRWwsMSM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=QDiE+fWLSDDrjIdd/EbcsFNZqtkuq5ogqdzLiseQVnATD0P/NtcuOwt+fBr4pvFl4 c3HG4kBloafaFNWSa9qQu3437kuu6w1jzInujPJHMY5KZJ6S9lDdkQSvA30KUeW57E vdgFdHPkJpXa6chy9fNM8i2nU31wH+NCZCK33l9tujGZotqFzs2468KIkhD7vg/xJ1 AwYvzBgOtw37zIbw1c1rLXPN2VmEjzdrF50V7dxgtmnp4ZHcji6j6MAOFRcsAqqg0s 5h2ZIkcW+oEggaC2VWtUDJNwuAqhcp0o8RVOHoH0176Q0cOa0U5oPUhtgmuEoy2aEq xLxXSSEsDNI6A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 492p2T73KvzCqkV for ; Thu, 16 Apr 2020 07:39:45 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-telemetry-07.txt Thread-Index: AQHWE1usaQTObtnTc0myKtzOmEe+E6h7OWxg Date: Thu, 16 Apr 2020 05:39:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149616A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158697873353.29013.4148200236781320443@ietfa.amsl.com> In-Reply-To: <158697873353.29013.4148200236781320443@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] I-D Action: draft-ietf-dots-telemetry-07.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: Thu, 16 Apr 2020 05:39:54 -0000 Hi all,=20 This is a minor revision with the following changes:=20 * add a NEW text and pointer to Block3/Block4 options but without any norma= tive language.=20 * add a clarification that attack level is implementation-specific (to addr= ess a comment from Meiling) * clarify that telemetry setup is not deleted when a DOTS session is lost. = Its validity depends on the association with a dots client domain, not a tr= ansport session.=20 * unit-status is mandatory when configuring units. * add a clarification about overlapping targets to cover resolving IP addre= sses of fqdns/uri/aliases.=20 * clarify that telemetry-notify-interval does not consider each "fragmented= " notification as a single notification (if blocks are used to send a notif= ication). * clarify that data included in some attributes assumes that any uri-query = filters are applied.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mercredi 15 avril 2020 21:26 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-telemetry-07.txt >=20 >=20 > 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. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Filename : draft-ietf-dots-telemetry-07.txt > Pages : 95 > Date : 2020-04-15 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal DDoS attack > mitigation. > It specifies the normal traffic baseline and attack traffic > telemetry > attributes a DOTS client can convey to its DOTS server in the > mitigation request, the mitigation status telemetry attributes a > DOTS > server can communicate to a DOTS client, and the mitigation > efficacy > telemetry attributes a DOTS client can communicate to a DOTS > server. > The telemetry attributes can assist the mitigator to choose the > DDoS > mitigation techniques and perform optimal DDoS attack mitigation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-telemetry-07 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-07 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Apr 20 05:07: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 F2C463A0BE9 for ; Mon, 20 Apr 2020 05:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] 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 lQ15KMT4jARM for ; Mon, 20 Apr 2020 05:07:01 -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 1CA0D3A0BF4 for ; Mon, 20 Apr 2020 05:07:00 -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 1jQVCR-0002HO-C7 for ietf-supjps-dots@ietf.org; Mon, 20 Apr 2020 13:06:55 +0100 From: "Jon Shallow" To: Date: Mon, 20 Apr 2020 13:06:49 +0100 Message-ID: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1026_01D61714.8DA95D40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYXDCmQwrX/OmZLRDqS1+FUPP8vAQ== Content-Language: en-gb Archived-At: Subject: [Dots] DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 12:07:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1026_01D61714.8DA95D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should the GET fail based on the telemetry-notify-interval, or should telemetry-notify-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/min information and telemetry-notify-interval can easily be more than 1 second. ] 2) Use of multiple Uri-Query: Uri-Query: target_prefix=[1.2.3.4] Uri-Query: target_prefix=[2.3.4.5] I think this should be OR Uri-Query: target_prefix=[1.2.3.4] Uri-Query: target_port=[80] I think this should be an AND. Perhaps we should have operator queries Uri-Query: target_prefix=[1.2.3.4] Uri-Query: op=OR Uri-Query: target_prefix=[2.3.4.5] Uri-Query: target_prefix=[1.2.3.4] Uri-Query: op=AND Uri-Query: target_port=[80] Thoughts? 3) What happens if a Query cannot be supported. E.g. Uri-Query: target_port=[80] and statistics on the server by a port basis is not supported. Do we want to either error out with a 4.0X responses, or should we include a (new additional) YANG body response indicating which Uri-Query is not supported? Regards Jon ------=_NextPart_000_1026_01D61714.8DA95D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

1)

   = DOTS agents MUST NOT send pre-or-ongoing-mitigation = telemetry

   messages to = the same peer more frequently than once every = 'telemetry-

   = notify-interval' (Section 6.1).

 

If I do a = PUT /tm-setup, followed immediately by a GET /tm-setup, should the GET = fail based on the telemetry-notify-interval, or should = telemetry-notify-interval apply individually to PUT. GET and = DELETE?

[I may want to do a DELETE = (no tsid) followed by a GET to get suitable max/min information and = telemetry-notify-interval can easily be more than 1 second. = ]

 

2)

Use of multiple = Uri-Query:

 

Uri-Query: target_prefix=3D[1.2.3.4]

Uri-Query: target_prefix=3D[2.3.4.5]

I think this should be OR

 

Uri-Query: = target_prefix=3D[1.2.3.4]

Uri-Query: = target_port=3D[80]

I think this = should be an AND.

 

Perhaps we = should have operator queries

Uri-Query: target_prefix=3D[1.2.3.4]

Uri-Query: op=3DOR

Uri-Query: target_prefix=3D[2.3.4.5]

 

Uri-Query: = target_prefix=3D[1.2.3.4]

Uri-Query: = op=3DAND

Uri-Query: = target_port=3D[80]

 

Thoughts?

 

3)

What happens if = a Query cannot be supported.

 

E.g. = Uri-Query: target_port=3D[80] and statistics on the server by a port = basis  is not supported.  Do we want to either error out with = a 4.0X responses, or should we include a (new additional) YANG body = response indicating which Uri-Query is not supported?

 

 

Regards

 

Jon

------=_NextPart_000_1026_01D61714.8DA95D40-- From nobody Mon Apr 20 05:54: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 B5F7D3A0C55 for ; Mon, 20 Apr 2020 05:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeGpU4xlh1T7 for ; Mon, 20 Apr 2020 05:54:03 -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 C82083A0C49 for ; Mon, 20 Apr 2020 05:54:02 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 495RTg4LX8zytb; Mon, 20 Apr 2020 14:53:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587387239; bh=WYF8UcTM+PFD7U7rnMHcULJ/JeRWFl+7z6Dmxo1gF7Q=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=LwYCHCzJaQU6Q+gUpYFBN7MhCQrYWlB6i25MbdRGMIK+JWn6UEBqd5H9Dwli/uypI 7xxlBOxT3Xt6AD+AJbbZnJDDbavlib3FE5bLVKxikphFiLPSknB+FOSJsWSHanJhaR 8hnxwgKFU04Dvb+0oRVQw8K8kdnG9UVdWVS0h5YMPV6gFkGQyjbFVf2DnR96/YpZCw WFUXCyhJPkwsI3Ilf1TRXxPTp8OrkucxUpPMbQLj7TJ3XoyC2xRuMCKsUpLzSOCPmx HUI396fg/8vXEQGhvVvY90NfwilqfW91e2hq8DtT7ZTTzdy/8lAauGRQ33FXyqEeyV nE+Ituk4EVtBw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 495RTg3YmpzDq7C; Mon, 20 Apr 2020 14:53:59 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS telemetry Issues picked up in Interop Testing Thread-Index: AdYXDCmQwrX/OmZLRDqS1+FUPP8vAQAA0JGA Date: Mon, 20 Apr 2020 12:53:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> In-Reply-To: <102501d6170c$2be45900$83ad0b00$@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_787AE7BB302AE849A7480A190F8B933031499776OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 12:54:10 -0000 --_000_787AE7BB302AE849A7480A190F8B933031499776OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Thank you for sharing the comments. Please see De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 20 avril 2020 14:07 =C0 : dots@ietf.org Objet : [Dots] DOTS telemetry Issues picked up in Interop Testing Hi All, 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should th= e GET fail based on the telemetry-notify-interval, or should telemetry-noti= fy-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/= min information and telemetry-notify-interval can easily be more than 1 sec= ond. ] [Med] This rate limit does not apply to these messages; it applies only for= notifications; =3D=3D leaf telemetry-notify-interval { type uint32 { range "1 .. 3600"; } must '. >=3D ../../min-config-values/telemetry-notify-interval' { error-message "The value must be greater than or equal to the telemetry-notify-interval in the min-config-values"; } units "seconds"; description "Minimum number of seconds between successive telemetry notifications."; } =3D=3D=3D We can make the text clear: OLD: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block]), this rate limit policy MUST NOT c= onsider these individual blocks as separate notifications, but as a single notification. NEW: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetr= y- notify-interval' (Section 6.1). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block]), this rate limit policy MUST NOT c= onsider these individual blocks as separate notifications, but as a single notification. 2) Use of multiple Uri-Query: Uri-Query: target_prefix=3D[1.2.3.4] Uri-Query: target_prefix=3D[2.3.4.5] I think this should be OR [Med] Yes, this is the same interpretation when we include target-prefix in= the message body. Uri-Query: target_prefix=3D[1.2.3.4] Uri-Query: target_port=3D[80] I think this should be an AND. [Med] Yes, because the target-port is specifying a subset of ports bound to= the target-prefix. Perhaps we should have operator queries Uri-Query: target_prefix=3D[1.2.3.4] Uri-Query: op=3DOR Uri-Query: target_prefix=3D[2.3.4.5] Uri-Query: target_prefix=3D[1.2.3.4] Uri-Query: op=3DAND Uri-Query: target_port=3D[80] [Med] I don't think this is needed. We don't specify the operator when we i= nclude the target clauses in the message body. The same rules apply. We can= clarify this in the text If you think this is needed. Thoughts? 3) What happens if a Query cannot be supported. E.g. Uri-Query: target_port=3D[80] and statistics on the server by a port b= asis is not supported. Do we want to either error out with a 4.0X respons= es, or should we include a (new additional) YANG body response indicating w= hich Uri-Query is not supported? [Med] Good point. The client can retrieve during telemetry setup the suppor= ted query types + server replies with 4.00 when an invalid query type is us= ed. Regards Jon --_000_787AE7BB302AE849A7480A190F8B933031499776OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thank you for sharing the comments.

 

Please see

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 20 avril 2020 14:07
=C0 : dots@ietf.org
Objet : [Dots] DOTS telemetry Issues picked up in Interop Testi= ng

 

Hi All,

 

1)

   DOTS agents MUST N= OT send pre-or-ongoing-mitigation telemetry

   messages to the sa= me peer more frequently than once every 'telemetry-

   notify-interval' (= Section 6.1).

 

If I do a PUT /tm-setup, follow= ed immediately by a GET /tm-setup, should the GET fail based on the telemet= ry-notify-interval, or should telemetry-notify-interval apply individually = to PUT. GET and DELETE?

[I may want to do a DELETE (no = tsid) followed by a GET to get suitable max/min information and telemetry-n= otify-interval can easily be more than 1 second. ]

 

[Med] This rate limit = does not apply to these messages; it applies only for notifications;

 

=3D=3D

      &nbs= p; leaf telemetry-notify-interval {

      &nbs= p;   type uint32 {

      &nbs= p;     range "1 .. 3600";

      &nbs= p;   }

      &nbs= p;   must '. >=3D ../../min-config-values/telemetry-notify-int= erval' {

      &nbs= p;     error-message

      &nbs= p;       "The value must be greater than= or equal

      &nbs= p;        to the telemetry-notify-interv= al in the min-config-values";

      &nbs= p;   }

      &nbs= p;   units "seconds";

      &nbs= p;   description

      &nbs= p;     "Minimum number of seconds between successi= ve

      &nbs= p;      telemetry notifications.";=

      &nbs= p; }

=3D=3D=3D

 

We can make the text c= lear:

 

OLD: 

   DOTS agents MUST NOT send pre-or-ongoing-mitigation =
telemetry
   messages to the same peer more frequently than once every=
 'telemetry-
   notify-interval' (Section 6.1).  If a tele=
metry notification is sent
   using a block-like transfer mechanism (e.g.,

   [I-D.bosh-core-n=
ew-block]), this rate limit policy MUST NOT consider


   these individual blocks as separate notifications, but as=
 a single


   notification.


 


NEW:=



   DOTS agents MUST NOT send pre-or-ongoing-mitigation telem=
etry


   notifications to the same peer more frequently than once =
every 'telemetry-


   notify-interval' (Section 6.1).  If a tele=
metry notification is sent


   using a block-like transfer mechanism (e.g.,

   [I-D.bosh-core-n=
ew-block]), this rate limit policy MUST NOT consider


   these individual blocks as separate notifications, but as=
 a single


   notification.


 


 


2)


Use of multiple Uri-Query:=



 


Uri-Query: target_prefix=3D[1.2=
.3.4]


Uri-Query: target_prefix=3D[2.3=
.4.5]


I think this should be OR<=
/o:p>


[Med] Yes, this is the=
 same interpretation when we include target-prefix in the message body.


 


Uri-Query: target_prefix=3D[1.2=
.3.4]


Uri-Query: target_port=3D[80]


I think this should be an AND.<=
o:p>


[Med] Yes, because the=
 target-port is specifying a subset of ports bound to the target-prefix. &n=
bsp;


 


Perhaps we should have operator=
 queries


Uri-Query: target_prefix=3D[1.2=
.3.4]


Uri-Query: op=3DOR


Uri-Query: target_prefix=3D[2.3=
.4.5]


 


Uri-Query: target_prefix=3D[1.2=
.3.4]


Uri-Query: op=3DAND<=
/span>


Uri-Query: target_port=3D[80]


[Med] I don’t th=
ink this is needed. We don’t specify the operator when we include the=
 target clauses in the message body. The same rules apply. We can clarify
 this in the text If you think this is needed.  


 


 


Thoughts?


 


3)


What happens if a Query cannot =
be supported.


 


E.g. Uri-Query: target_port=3D[=
80] and statistics on the server by a port basis  is not supported.&nb=
sp; Do we want to either error out with a 4.0X responses, or should we incl=
ude a (new additional) YANG body response indicating
 which Uri-Query is not supported?


&n=
bsp;


[Med] Good point. The =
client can retrieve during telemetry setup the supported query types + =
server replies with 4.00 when an invalid query type is used.



 


Regards


 


Jon
--_000_787AE7BB302AE849A7480A190F8B933031499776OPEXCAUBMA2corp_-- From nobody Mon Apr 20 06:46:51 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 DC74D3A0D7A for ; Mon, 20 Apr 2020 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 MKyNlPAJyVNM for ; Mon, 20 Apr 2020 06:46:45 -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 2489D3A0D77 for ; Mon, 20 Apr 2020 06:46:43 -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 1jQWkw-0002LZ-GA; Mon, 20 Apr 2020 14:46:38 +0100 From: "Jon Shallow" To: , References: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 20 Apr 2020 14:46:32 +0100 Message-ID: <105901d6171a$1a132860$4e397920$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_105A_01D61722.7BD91700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIP9ThI7DkLoYVsg/jsxFxzT+JmLAHYmGmap/+EM3A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 13:46:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_105A_01D61722.7BD91700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair@orange.com Sent: 20 April 2020 13:54 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi Jon,=20 =20 Thank you for sharing the comments.=20 =20 Please see =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 20 avril 2020 14:07 =C0 : dots@ietf.org Objet : [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi All, =20 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). =20 If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should = the GET fail based on the telemetry-notify-interval, or should telemetry-notify-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/min information and telemetry-notify-interval can easily be more = than 1 second. ] =20 [Med] This rate limit does not apply to these messages; it applies only = for notifications;=20 =20 =3D=3D leaf telemetry-notify-interval { type uint32 { range "1 .. 3600"; } must '. >=3D = ../../min-config-values/telemetry-notify-interval' { error-message "The value must be greater than or equal to the telemetry-notify-interval in the = min-config-values"; } units "seconds"; description "Minimum number of seconds between successive telemetry notifications."; } =3D=3D=3D =20 We can make the text clear:=20 =20 OLD:=20 DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1 = ). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block ]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. =20 NEW: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1 = ). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block ]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. =20 Jon> This change works for me. =20 2) Use of multiple Uri-Query: =20 Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_prefix=3D[2.3..4.5] I think this should be OR [Med] Yes, this is the same interpretation when we include target-prefix = in the message body. =20 Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_port=3D[80] I think this should be an AND. [Med] Yes, because the target-port is specifying a subset of ports bound = to the target-prefix. =20 =20 Perhaps we should have operator queries Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DOR Uri-Query: target_prefix=3D[2.3..4.5] =20 Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DAND Uri-Query: target_port=3D[80] [Med] I don=92t think this is needed. We don=92t specify the operator = when we include the target clauses in the message body. The same rules apply. We = can clarify this in the text If you think this is needed. =20 =20 Jon> I think that it is worth stating that the same rules apply for clarification.=20 =20 Thoughts? =20 3) What happens if a Query cannot be supported. =20 E.g. Uri-Query: target_port=3D[80] and statistics on the server by a = port basis is not supported. Do we want to either error out with a 4.0X responses, or should we include a (new additional) YANG body response indicating which Uri-Query is not supported? =20 [Med] Good point. The client can retrieve during telemetry setup the supported query types + server replies with 4.00 when an invalid query = type is used.=20 =20 Jon> I think the server stating what Queries are supported is a good = idea. =20 Regards =20 Jon ------=_NextPart_000_105A_01D61722.7BD91700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See = inline.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = iemohamed.boucadair@orange.com
Sent: 20 April 2020 = 13:54
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS telemetry Issues picked up in Interop = Testing

 

Hi Jon, =

 

Thank you for sharing the comments. =

 

Please see

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : lundi 20 avril 2020 = 14:07
=C0 : dots@ietf.org
Objet : [Dots] = DOTS telemetry Issues picked up in Interop = Testing

 

Hi = All,

 

1)

   = DOTS agents MUST NOT send pre-or-ongoing-mitigation = telemetry

   messages to = the same peer more frequently than once every = 'telemetry-

   = notify-interval' (Section 6.1).

 

If I do a = PUT /tm-setup, followed immediately by a GET /tm-setup, should the GET = fail based on the telemetry-notify-interval, or should = telemetry-notify-interval apply individually to PUT. GET and = DELETE?

[I may want to do a DELETE = (no tsid) followed by a GET to get suitable max/min information and = telemetry-notify-interval can easily be more than 1 second. = ]

 

[Med] This rate limit does not apply to these = messages; it applies only for notifications; =

 

=3D=3D

        leaf = telemetry-notify-interval {

          type uint32 = {

            = range "1 .. 3600";

          = }

          must '. = >=3D ../../min-config-values/telemetry-notify-interval' = {

        =     error-message

           &= nbsp;  "The value must be greater than or = equal

           &= nbsp;   to the telemetry-notify-interval in the = min-config-values";

          = }

          units = "seconds";

          = description

            = "Minimum number of seconds between = successive

           &= nbsp; telemetry notifications.";

        = }

=3D=3D=3D

 

We can make the text clear: =

 

OLD: 

   DOTS agents MUST NOT send =
pre-or-ongoing-mitigation telemetry
   messages to the same peer more frequently than =
once every 'telemetry-
   notify-interval' (Section 6.1).  If a telemetry notification is =
sent
   using a =
block-like transfer mechanism (e.g.,
   [I-D.bosh-core-new-block]), =
this rate limit policy MUST NOT =
consider
 =
  these individual blocks as separate notifications, but as a =
single
   =
notification.

 

NEW:

   DOTS agents MUST NOT send =
pre-or-ongoing-mitigation telemetry
   notifications to the same peer more frequently =
than once every 'telemetry-
   notify-interval' (Section 6.1).  If a telemetry notification is =
sent
   using a =
block-like transfer mechanism (e.g.,
   [I-D.bosh-core-new-block]), =
this rate limit policy MUST NOT =
consider
   =
these individual blocks as separate notifications, but as a =
single
   =
notification.

 

Jon> This change = works for me.

 

2)

Use of multiple = Uri-Query:

 

Uri-Query: target_prefix=3D[1.2..3.4]

Uri-Query: target_prefix=3D[2.3..4.5]

I think this should be OR

[Med] Yes, this is the same interpretation when we = include target-prefix in the message body.

 

Uri-Query: = target_prefix=3D[1.2..3.4]

Uri-Query: = target_port=3D[80]

I think this = should be an AND.

[Med] Yes, because the = target-port is specifying a subset of ports bound to the target-prefix. =  

 

Perhaps we = should have operator queries

Uri-Query: target_prefix=3D[1.2..3.4]

Uri-Query: op=3DOR

Uri-Query: target_prefix=3D[2.3..4.5]

 

Uri-Query: = target_prefix=3D[1.2..3.4]

Uri-Query: = op=3DAND

Uri-Query: = target_port=3D[80]

[Med] I don’t = think this is needed. We don’t specify the operator when we = include the target clauses in the message body. The same rules apply. We = can clarify this in the text If you think this is needed. =  

 

Jon> I think that it = is worth stating that the same rules apply for clarification. =

 

Thoughts?

 

3)

What happens if = a Query cannot be supported.

 

E.g. = Uri-Query: target_port=3D[80] and statistics on the server by a port = basis  is not supported.  Do we want to either error out with = a 4.0X responses, or should we include a (new additional) YANG body = response indicating which Uri-Query is not supported?

 

[Med] Good point. The client can retrieve during = telemetry setup the supported query types + server replies with 4.00 = when an invalid query type is used.

 

Jon> I think the = server stating what Queries are supported is a good = idea.

 

Regards

 

Jon

------=_NextPart_000_105A_01D61722.7BD91700-- From nobody Mon Apr 20 08:49:03 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 1D1C03A098A for ; Mon, 20 Apr 2020 08:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_SGhgCmhI72 for ; Mon, 20 Apr 2020 08:48:55 -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 5E9D73A09CB for ; Mon, 20 Apr 2020 08:46:52 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 495WK52nTyz8vsb; Mon, 20 Apr 2020 17:46:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587397609; bh=tSMXv5mpPkP6Lrt4LeMcv6/KD2hS7BPYCy4K0F8unB0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=uW7URgTVPFA8nAH0xuM4xeP0jpMmgWOV0eq9NuIaO+0GISiSdZo3/Pj9sWSQATDz/ yVy+cr84a5iNPAjaro+gPliJLFNScbF6RVQfhOg7mSN9K+HrOkNSiUBxhSHM0gEAT5 ronb0dkGSRIdeFmTO47rFbdJFgwjanPcM0rMKqTzUvFY3+JCdNu/YGklklhRHdZwrl dcidnSZ7hXiAzrBSli0r84ahKEQJm7BWSPrIbvs8zPT8ZULogKSxT+IOB4QXhTlRLY oTlOtIOd2CgSg8qr2rXJQo0q0uExC5CBlPv/lFDA4Ptrlz2c74rlzASB/1fMFskjtV Dj5LWykvplMlA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 495WK51t4szCqkV; Mon, 20 Apr 2020 17:46:49 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS telemetry Issues picked up in Interop Testing Thread-Index: AQIP9ThI7DkLoYVsg/jsxFxzT+JmLAHYmGmap/+EM3CAACIu0A== Date: Mon, 20 Apr 2020 15:46:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031499A6F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <105901d6171a$1a132860$4e397920$@jpshallow.com> In-Reply-To: <105901d6171a$1a132860$4e397920$@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_787AE7BB302AE849A7480A190F8B933031499A6FOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 15:49:01 -0000 --_000_787AE7BB302AE849A7480A190F8B933031499A6FOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, FWIW, I implemented the agreed changes at: https://github.com/boucadair/dra= ft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-07.txt Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 20 avril 2020 15:47 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi Med, See inline. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair= @orange.com Sent: 20 April 2020 13:54 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi Jon, Thank you for sharing the comments. Please see De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 20 avril 2020 14:07 =C0 : dots@ietf.org Objet : [Dots] DOTS telemetry Issues picked up in Interop Testing Hi All, 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should th= e GET fail based on the telemetry-notify-interval, or should telemetry-noti= fy-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/= min information and telemetry-notify-interval can easily be more than 1 sec= ond. ] [Med] This rate limit does not apply to these messages; it applies only for= notifications; =3D=3D leaf telemetry-notify-interval { type uint32 { range "1 .. 3600"; } must '. >=3D ../../min-config-values/telemetry-notify-interval' { error-message "The value must be greater than or equal to the telemetry-notify-interval in the min-config-values"; } units "seconds"; description "Minimum number of seconds between successive telemetry notifications."; } =3D=3D=3D We can make the text clear: OLD: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block]), this rate limit policy MUST NOT c= onsider these individual blocks as separate notifications, but as a single notification. NEW: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetr= y- notify-interval' (Section 6.1). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block]), this rate limit policy MUST NOT c= onsider these individual blocks as separate notifications, but as a single notification. Jon> This change works for me. 2) Use of multiple Uri-Query: Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_prefix=3D[2.3..4.5] I think this should be OR [Med] Yes, this is the same interpretation when we include target-prefix in= the message body. Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_port=3D[80] I think this should be an AND. [Med] Yes, because the target-port is specifying a subset of ports bound to= the target-prefix. Perhaps we should have operator queries Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DOR Uri-Query: target_prefix=3D[2.3..4.5] Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DAND Uri-Query: target_port=3D[80] [Med] I don't think this is needed. We don't specify the operator when we i= nclude the target clauses in the message body. The same rules apply. We can= clarify this in the text If you think this is needed. Jon> I think that it is worth stating that the same rules apply for clarifi= cation. Thoughts? 3) What happens if a Query cannot be supported. E.g. Uri-Query: target_port=3D[80] and statistics on the server by a port b= asis is not supported. Do we want to either error out with a 4.0X respons= es, or should we include a (new additional) YANG body response indicating w= hich Uri-Query is not supported? [Med] Good point. The client can retrieve during telemetry setup the suppor= ted query types + server replies with 4.00 when an invalid query type is us= ed. Jon> I think the server stating what Queries are supported is a good idea. Regards Jon --_000_787AE7BB302AE849A7480A190F8B933031499A6FOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

FWIW, I implemented the agreed changes at: https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-do= ts-telemetry-07.txt

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 20 avril 2020 15:47
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop T= esting

 

Hi Med,=

&n= bsp;

See inl= ine.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair@orange.com
Sent: 20 April 2020 13:54
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testi= ng

 

Hi Jon,

 

Thank you for sharing the comments.

 

Please see

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 20 avril 2020 14:07
=C0 : dots@ietf.org
Objet : [Dots] DOTS telemetry Issues picked up in Interop Testi= ng

 

Hi All,

 

1)

   DOTS agents MUST N= OT send pre-or-ongoing-mitigation telemetry

   messages to the sa= me peer more frequently than once every 'telemetry-

   notify-interval' (= Section 6.1).

 

If I do a PUT /tm-setup, follow= ed immediately by a GET /tm-setup, should the GET fail based on the telemet= ry-notify-interval, or should telemetry-notify-interval apply individually = to PUT. GET and DELETE?

[I may want to do a DELETE (no = tsid) followed by a GET to get suitable max/min information and telemetry-n= otify-interval can easily be more than 1 second. ]

 

[Med] This rate limit = does not apply to these messages; it applies only for notifications;

 

=3D=3D

      &nbs= p; leaf telemetry-notify-interval {

      &nbs= p;   type uint32 {

      &nbs= p;     range "1 .. 3600";

      &nbs= p;   }

      &nbs= p;   must '. >=3D ../../min-config-values/telemetry-notify-int= erval' {

      &nbs= p;     error-message

      &nbs= p;       "The value must be greater than= or equal

      &nbs= p;        to the telemetry-notify-interv= al in the min-config-values";

      &nbs= p;   }

      &nbs= p;   units "seconds";

      &nbs= p;   description

      &nbs= p;     "Minimum number of seconds between successi= ve

      &nbs= p;      telemetry notifications.";=

      &nbs= p; }

=3D=3D=3D

 

We can make the text c= lear:

 

OLD: 

   DOTS agents MUST NOT send pre-or-ongoing=
-mitigation telemetry
   messages to the same peer more frequently tha=
n once every 'telemetry-
   notify-interval' (Section 6.1).&nbs=
p; If a telemetry notification is sent
   using a block-like transfer mechanism (e.g.,<=
o:p>
   [I-D=
.bosh-core-new-block]), this rate limit policy MUST NOT consider
   these individual blocks as separate notificat=
ions, but as a single
   notification.

 

NEW:= 

   DOTS agents MUST NOT send pre-or-ongoing-miti=
gation telemetry
   notifications to the same peer more frequentl=
y than once every 'telemetry-
   notify-interval' (Section 6.1).&nbs=
p; If a telemetry notification is sent
   using a block-like transfer mechanism (e.g.,<=
o:p>
   [I-D=
.bosh-core-new-block]), this rate limit policy MUST NOT consider
   these individual blocks as separate notificat=
ions, but as a single
   notification.

 

Jon>= This change works for me.

 

2)

Use of multiple Uri-Query:=

 

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: target_prefix=3D[2.3= ..4.5]

I think this should be OR<= /o:p>

[Med] Yes, this is the= same interpretation when we include target-prefix in the message body.

 

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: target_port=3D[80]

I think this should be an AND.<= o:p>

[Med] Yes, because the= target-port is specifying a subset of ports bound to the target-prefix. &n= bsp;

 

Perhaps we should have operator= queries

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: op=3DOR

Uri-Query: target_prefix=3D[2.3= ..4.5]

 

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: op=3DAND<= /span>

Uri-Query: target_port=3D[80]

[Med] I don’t th= ink this is needed. We don’t specify the operator when we include the= target clauses in the message body. The same rules apply. We can clarify this in the text If you think this is needed.  

 

Jon>= I think that it is worth stating that the same rules apply for clarificati= on.

 

Thoughts?

 

3)

What happens if a Query cannot = be supported.

 

E.g. Uri-Query: target_port=3D[= 80] and statistics on the server by a port basis  is not supported.&nb= sp; Do we want to either error out with a 4.0X responses, or should we incl= ude a (new additional) YANG body response indicating which Uri-Query is not supported?

&n= bsp;

[Med] Good point. The = client can retrieve during telemetry setup the supported query types + = server replies with 4.00 when an invalid query type is used.

&n= bsp;

Jon>= I think the server stating what Queries are supported is a good idea.=

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B933031499A6FOPEXCAUBMA2corp_-- From nobody Tue Apr 21 01:59: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 AC5013A09D9 for ; Tue, 21 Apr 2020 01:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 y4JQ3sjD0sgk for ; Tue, 21 Apr 2020 01:59:32 -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 0A7CA3A09F2 for ; Tue, 21 Apr 2020 01:59:26 -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 1jQokT-0003Fv-2Y; Tue, 21 Apr 2020 09:59:21 +0100 From: "Jon Shallow" To: , References: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <105901d6171a$1a132860$4e397920$@jpshallow.com> In-Reply-To: <105901d6171a$1a132860$4e397920$@jpshallow.com> Date: Tue, 21 Apr 2020 09:59:14 +0100 Message-ID: <114601d617bb$21c1cac0$65456040$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1147_01D617C3.83894000" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIP9ThI7DkLoYVsg/jsxFxzT+JmLAHYmGmaAtdF3C+n6gdd4A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 08:59:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1147_01D617C3.83894000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 A further thought on the use of Uri-Queries to clarify the AND/OR usage. =20 If you only allow one query per query type and put the match list in an array, then this will be an OR of the array list (the same as we do for = the target* definitions right now. E.G. :- =20 Uri-Query: target_prefix=3D[1.2.3.4/32,4.3.2.1/32] Gives either 1.2.3.4 or 4.3.2.1 as a valid match. =20 And=20 Uri-Query: target-prefix=3D[1.2.3.4/32,4.3.2.1/32] Uri-Query: lower-port=3D[80,443] Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443) =20 [] should not include spaces and comma used as a separator. =20 Not sure about :- If [] are not used, then it should be treated as a = single item to match. =20 The list of valid Uri-Queries may need to be extended. =20 A Uri-Query option can include the following parameters: target-prefix, lower-port, upper-port, target-protocol, target-fqdn, target-uri, alias-name. =20 should include mid and content (=91c=92). Do we need to be able to = filter on source attributes as well? =20 Regards =20 Jon =20 =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 20 April 2020 14:47 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi Med, =20 See inline. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair@orange.com Sent: 20 April 2020 13:54 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi Jon,=20 =20 Thank you for sharing the comments.=20 =20 Please see =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 20 avril 2020 14:07 =C0 : dots@ietf.org Objet : [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi All, =20 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). =20 If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should = the GET fail based on the telemetry-notify-interval, or should telemetry-notify-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/min information and telemetry-notify-interval can easily be more = than 1 second. ] =20 [Med] This rate limit does not apply to these messages; it applies only = for notifications;=20 =20 =3D=3D leaf telemetry-notify-interval { type uint32 { range "1 .. 3600"; } must '. >=3D = ../../min-config-values/telemetry-notify-interval' { error-message "The value must be greater than or equal to the telemetry-notify-interval in the = min-config-values"; } units "seconds"; description "Minimum number of seconds between successive telemetry notifications."; } =3D=3D=3D =20 We can make the text clear:=20 =20 OLD:=20 DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1 = ). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block ]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. =20 NEW: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1 = ). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block ]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. =20 Jon> This change works for me. =20 2) Use of multiple Uri-Query: =20 Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_prefix=3D[2.3..4.5] I think this should be OR [Med] Yes, this is the same interpretation when we include target-prefix = in the message body. =20 Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_port=3D[80] I think this should be an AND. [Med] Yes, because the target-port is specifying a subset of ports bound = to the target-prefix. =20 =20 Perhaps we should have operator queries Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DOR Uri-Query: target_prefix=3D[2.3..4.5] =20 Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DAND Uri-Query: target_port=3D[80] [Med] I don=92t think this is needed. We don=92t specify the operator = when we include the target clauses in the message body. The same rules apply. We = can clarify this in the text If you think this is needed. =20 =20 Jon> I think that it is worth stating that the same rules apply for clarification.=20 =20 Thoughts? =20 3) What happens if a Query cannot be supported. =20 E.g. Uri-Query: target_port=3D[80] and statistics on the server by a = port basis is not supported. Do we want to either error out with a 4.0X responses, or should we include a (new additional) YANG body response indicating which Uri-Query is not supported? =20 [Med] Good point. The client can retrieve during telemetry setup the supported query types + server replies with 4.00 when an invalid query = type is used.=20 =20 Jon> I think the server stating what Queries are supported is a good = idea. =20 Regards =20 Jon ------=_NextPart_000_1147_01D617C3.83894000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

A further thought on the = use of Uri-Queries to clarify the AND/OR usage.

 

If you only allow one = query per query type and put the match list in an array, then this will = be an OR of the array list (the same as we do for the target* = definitions right now.=A0 E.G. :-

 

Uri-Query: = target_prefix=3D[1.2.3.4/32,4.3.2.1/32]

Gives either 1.2.3.4 or = 4.3.2.1 as a valid match.

 

And =

Uri-Query: = target-prefix=3D[1.2.3.4/32,4.3.2.1/32]

Uri-Query: = lower-port=3D[80,443]

Gives (either 1.2.3.4 or 4.3.2.1) and (either = port 80 or 443)

 

[] should not include = spaces and comma used as a separator.

 

Not sure about :-=A0 If = [] are not used, then it should be treated as a single item to = match.

 

The list of valid = Uri-Queries may need to be extended.

 

A Uri-Query option can = include the following

=A0=A0 parameters: target-prefix, lower-port, = upper-port, target-protocol,

=A0=A0 target-fqdn, = target-uri, alias-name.

 

should include mid and = content (‘c’).=A0=A0 Do we need to be able to filter on = source attributes as well?

 

Regards

 

Jon

 

 

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: 20 April 2020 14:47
To: = mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: = [Dots] DOTS telemetry Issues picked up in Interop = Testing

 

Hi Med,

 

See = inline.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = iemohamed.boucadair@orange.com
Sent: 20 April 2020 = 13:54
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS telemetry Issues picked up in Interop = Testing

 

Hi Jon, =

 

Thank you for sharing the comments. =

 

Please see

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : lundi 20 avril 2020 = 14:07
=C0 : dots@ietf.org
Objet : [Dots] = DOTS telemetry Issues picked up in Interop = Testing

 

Hi = All,

 

1)

   = DOTS agents MUST NOT send pre-or-ongoing-mitigation = telemetry

   messages to = the same peer more frequently than once every = 'telemetry-

   = notify-interval' (Section 6.1).

 

If I do a = PUT /tm-setup, followed immediately by a GET /tm-setup, should the GET = fail based on the telemetry-notify-interval, or should = telemetry-notify-interval apply individually to PUT. GET and = DELETE?

[I may want to do a DELETE = (no tsid) followed by a GET to get suitable max/min information and = telemetry-notify-interval can easily be more than 1 second. = ]

 

[Med] This rate limit does not apply to these = messages; it applies only for notifications; =

 

=3D=3D

        leaf = telemetry-notify-interval {

          type uint32 = {

            = range "1 .. 3600";

          = }

          must '. = >=3D ../../min-config-values/telemetry-notify-interval' = {

        =     error-message

           &= nbsp;  "The value must be greater than or = equal

           &= nbsp;   to the telemetry-notify-interval in the = min-config-values";

          = }

          units = "seconds";

          = description

            = "Minimum number of seconds between = successive

           &= nbsp; telemetry notifications.";

        = }

=3D=3D=3D

 

We can make the text clear: =

 

OLD: 

   DOTS agents MUST NOT send =
pre-or-ongoing-mitigation telemetry
   messages to the same peer more frequently than =
once every 'telemetry-
   notify-interval' (Section 6.1).  If a telemetry notification is =
sent
   using a =
block-like transfer mechanism (e.g.,
   [I-D.bosh-core-new-block]), =
this rate limit policy MUST NOT =
consider
 =
  these individual blocks as separate notifications, but as a =
single
   =
notification.

 

NEW:

   DOTS agents MUST NOT send =
pre-or-ongoing-mitigation telemetry
   notifications to the same peer more frequently =
than once every 'telemetry-
   notify-interval' (Section 6.1).  If a telemetry notification is =
sent
   using a =
block-like transfer mechanism (e.g.,
   [I-D.bosh-core-new-block]), =
this rate limit policy MUST NOT =
consider
   =
these individual blocks as separate notifications, but as a =
single
   =
notification.

 

Jon> This change = works for me.

 

2)

Use of multiple = Uri-Query:

 

Uri-Query: target_prefix=3D[1.2..3.4]

Uri-Query: target_prefix=3D[2.3..4.5]

I think this should be OR

[Med] Yes, this is the same interpretation when we = include target-prefix in the message body.

 

Uri-Query: = target_prefix=3D[1.2..3.4]

Uri-Query: = target_port=3D[80]

I think this = should be an AND.

[Med] Yes, because the = target-port is specifying a subset of ports bound to the target-prefix. =  

 

Perhaps we = should have operator queries

Uri-Query: target_prefix=3D[1.2..3.4]

Uri-Query: op=3DOR

Uri-Query: target_prefix=3D[2.3..4.5]

 

Uri-Query: = target_prefix=3D[1.2..3.4]

Uri-Query: = op=3DAND

Uri-Query: = target_port=3D[80]

[Med] I don’t = think this is needed. We don’t specify the operator when we = include the target clauses in the message body. The same rules apply. We = can clarify this in the text If you think this is needed. =  

 

Jon> I think that it = is worth stating that the same rules apply for clarification. =

 

Thoughts?

 

3)

What happens if = a Query cannot be supported.

 

E.g. = Uri-Query: target_port=3D[80] and statistics on the server by a port = basis  is not supported.  Do we want to either error out with = a 4.0X responses, or should we include a (new additional) YANG body = response indicating which Uri-Query is not supported?

 

[Med] Good point. The client can retrieve during = telemetry setup the supported query types + server replies with 4.00 = when an invalid query type is used.

 

Jon> I think the = server stating what Queries are supported is a good = idea.

 

Regards

 

Jon

------=_NextPart_000_1147_01D617C3.83894000-- From nobody Tue Apr 21 03:04: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 AE1993A0B41 for ; Tue, 21 Apr 2020 03:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps5WFPu9gzFg for ; Tue, 21 Apr 2020 03:04: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 954333A0B46 for ; Tue, 21 Apr 2020 03:04:07 -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 opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 495zg92hhvz7tq4; Tue, 21 Apr 2020 12:04:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587463445; bh=Hkd0uTpJkYg3GhMZf6hC0FCPsQ2StLvRbt/9IHPY0p4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=VzM/cV1jjvU9R8wxHXVRGuarlz+MEMTYz3AuGXOFBLU11v5DgBuNmSOI15hywQhYl RkEJMoOcjdrrS0TUD1P0TOktIlJOMuGc2GzQF05ECrNDJwYY6/oqPcWY56JovlFn+4 tONQktYQBDEFIFm2q4Tt5rq0/+ShIfl742jo98YnbZh/TTmisUx0tuJ+zMBjU65nYb j3B4jbo4bx38FEE3mDhYeXapB/57XS3sFhwsTOeVDOmqudhff5jWEr+is0ihT7xqej V+7sbw3gn1QmFVmiBLVUtpdKnyxzt7Vl/dwjGSGw/896fHxzGZWFuT+hyG7a+h/UlY B+6Uj/a4Xam6w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 495zg91YyqzCqjh; Tue, 21 Apr 2020 12:04:05 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS telemetry Issues picked up in Interop Testing Thread-Index: AQIP9ThI7DkLoYVsg/jsxFxzT+JmLAHYmGmaAtdF3C+n6gdd4IAADrMA Date: Tue, 21 Apr 2020 10:04:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149B39C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <105901d6171a$1a132860$4e397920$@jpshallow.com> <114601d617bb$21c1cac0$65456040$@jpshallow.com> In-Reply-To: <114601d617bb$21c1cac0$65456040$@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_787AE7BB302AE849A7480A190F8B93303149B39COPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 10:04:12 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149B39COPEXCAUBMA2corp_ 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 : mardi 21 avril 2020 10:59 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi all, A further thought on the use of Uri-Queries to clarify the AND/OR usage. If you only allow one query per query type and put the match list in an arr= ay, then this will be an OR of the array list (the same as we do for the ta= rget* definitions right now. E.G. :- Uri-Query: target_prefix=3D[1.2.3.4/32,4.3.2.1/32] Gives either 1.2.3.4 or 4.3.2.1 as a valid match. And Uri-Query: target-prefix=3D[1.2.3.4/32,4.3.2.1/32] Uri-Query: lower-port=3D[80,443] Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443) [] should not include spaces and comma used as a separator. [Med] The issue I have with this is that we will need to handle cases where= both lower-port and upper-port are present. Not sure what would be the ben= efit of allowing multiple key values, compact uris? If that's a concern, we= may consider shortened names in the query (e.g., s/target-prefix/tp, s/low= er-port/lp, ..). Not sure about :- If [] are not used, then it should be treated as a singl= e item to match. The list of valid Uri-Queries may need to be extended. A Uri-Query option can include the following parameters: target-prefix, lower-port, upper-port, target-protocol, target-fqdn, target-uri, alias-name. should include mid and content ('c'). [Med] OK. Please note that 'c' wasn't listed because we do have the followi= ng: The DOTS server follows the same considerations discussed in Section of 4.5.3 of [I-D.ietf-dots-signal-channel] for managing DOTS telemetry configuration freshness and notification. Likewise, a DOTS client may control the selection of configuration and non- configuration data nodes when sending a GET request by means of the 'c' Uri-Query option and following the procedure specified in Section of 4.4.2 of [I-D.ietf-dots-signal-channel]. These considerations are not re-iterated in the following sections. I added a pointer to that section. Do we need to be able to filter on source attributes as well? [Med] What would be the usage? Is it the case of an administrator that is a= ware (using some means) that some sources are involved an attacks on other = networks, then sends a request to its server to filter telemetry data bound= to these source? Filtering in this case may be problematic as some attacks= may be observed but are hidden by the filter on the source. Or do we want = to focus on very few talkers? For example, the client would instruct the se= rver to send data only related to the top-talker, 3 first top-talkers, etc.= ? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 20 April 2020 14:47 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi Med, See inline. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair= @orange.com Sent: 20 April 2020 13:54 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi Jon, Thank you for sharing the comments. Please see De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 20 avril 2020 14:07 =C0 : dots@ietf.org Objet : [Dots] DOTS telemetry Issues picked up in Interop Testing Hi All, 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should th= e GET fail based on the telemetry-notify-interval, or should telemetry-noti= fy-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/= min information and telemetry-notify-interval can easily be more than 1 sec= ond. ] [Med] This rate limit does not apply to these messages; it applies only for= notifications; =3D=3D leaf telemetry-notify-interval { type uint32 { range "1 .. 3600"; } must '. >=3D ../../min-config-values/telemetry-notify-interval' { error-message "The value must be greater than or equal to the telemetry-notify-interval in the min-config-values"; } units "seconds"; description "Minimum number of seconds between successive telemetry notifications."; } =3D=3D=3D We can make the text clear: OLD: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block]), this rate limit policy MUST NOT c= onsider these individual blocks as separate notifications, but as a single notification. NEW: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetr= y- notify-interval' (Section 6.1). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D.bosh-core-new-block]), this rate limit policy MUST NOT c= onsider these individual blocks as separate notifications, but as a single notification. Jon> This change works for me. 2) Use of multiple Uri-Query: Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_prefix=3D[2.3..4.5] I think this should be OR [Med] Yes, this is the same interpretation when we include target-prefix in= the message body. Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: target_port=3D[80] I think this should be an AND. [Med] Yes, because the target-port is specifying a subset of ports bound to= the target-prefix. Perhaps we should have operator queries Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DOR Uri-Query: target_prefix=3D[2.3..4.5] Uri-Query: target_prefix=3D[1.2..3.4] Uri-Query: op=3DAND Uri-Query: target_port=3D[80] [Med] I don't think this is needed. We don't specify the operator when we i= nclude the target clauses in the message body. The same rules apply. We can= clarify this in the text If you think this is needed. Jon> I think that it is worth stating that the same rules apply for clarifi= cation. Thoughts? 3) What happens if a Query cannot be supported. E.g. Uri-Query: target_port=3D[80] and statistics on the server by a port b= asis is not supported. Do we want to either error out with a 4.0X respons= es, or should we include a (new additional) YANG body response indicating w= hich Uri-Query is not supported? [Med] Good point. The client can retrieve during telemetry setup the suppor= ted query types + server replies with 4.00 when an invalid query type is us= ed. Jon> I think the server stating what Queries are supported is a good idea. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93303149B39COPEXCAUBMA2corp_ 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 : mardi 21 avril 2020 10:59
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop T= esting

 

Hi all,=

&n= bsp;

A furth= er thought on the use of Uri-Queries to clarify the AND/OR usage.

&n= bsp;

If you = only allow one query per query type and put the match list in an array, the= n this will be an OR of the array list (the same as we do for the target* d= efinitions right now.  E.G. :-

&n= bsp;

Uri-Que= ry: target_prefix=3D[1.2.3.4/32,4.3.2.1/32]

Gives e= ither 1.2.3.4 or 4.3.2.1 as a valid match.

&n= bsp;

And

Uri-Que= ry: target-prefix=3D[1.2.3.4/32,4.3.2.1/32]

Uri-Que= ry: lower-port=3D[80,443]

Gives (= either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443)

&n= bsp;

[] shou= ld not include spaces and comma used as a separator.

&n= bsp;

[Med] The issue I have= with this is that we will need to handle cases where both lower-port and u= pper-port are present. Not sure what would be the benefit of allowing multiple key values, compact uris? If that’s a concern, = we may consider shortened names in the query (e.g., s/target-prefix/tp, s/l= ower-port/lp, ..).

 

Not sur= e about :-  If [] are not used, then it should be treated as a single = item to match.

&n= bsp;

The lis= t of valid Uri-Queries may need to be extended.

&n= bsp;

A Uri-Q= uery option can include the following

 &= nbsp; parameters: target-prefix, lower-port, upper-port, target-protocol,

 &= nbsp; target-fqdn, target-uri, alias-name.

&n= bsp;

should = include mid and content (‘c’). 

[Med] OK. Please note = that ‘c’ wasn’t listed because we do have the following:<= o:p>

 

  The DOTS server follows the same = considerations discussed in

   Section of 4.5.3 of [I-D.ie= tf-dots-signal-channel] for managing DOTS

   telemetry configuration fre= shness and notification.  Likewise, a DOTS

   client may control the sele= ction of configuration and non-

   configuration data nodes wh= en sending a GET request by means of the

   'c' Uri-Query option and fo= llowing the procedure specified in

   Section of 4.4.2 of [I-D.ie= tf-dots-signal-channel].  These

   considerations are not re-i= terated in the following sections.

 

I added a pointer to t= hat section.

 

  = Do we need to be able to filter on source attributes as well?

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

 

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 20 April 2020 14:47
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testi= ng

 

Hi Med,=

&n= bsp;

See inl= ine.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair@orange.com
Sent: 20 April 2020 13:54
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testi= ng

 

Hi Jon,

 

Thank you for sharing the comments.

 

Please see

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 20 avril 2020 14:07
=C0 : dots@ietf.org
Objet : [Dots] DOTS telemetry Issues picked up in Interop Testi= ng

 

Hi All,

 

1)

   DOTS agents MUST N= OT send pre-or-ongoing-mitigation telemetry

   messages to the sa= me peer more frequently than once every 'telemetry-

   notify-interval' (= Section 6.1).

 

If I do a PUT /tm-setup, follow= ed immediately by a GET /tm-setup, should the GET fail based on the telemet= ry-notify-interval, or should telemetry-notify-interval apply individually = to PUT. GET and DELETE?

[I may want to do a DELETE (no = tsid) followed by a GET to get suitable max/min information and telemetry-n= otify-interval can easily be more than 1 second. ]

 

[Med] This rate limit = does not apply to these messages; it applies only for notifications;

 

=3D=3D

      &nbs= p; leaf telemetry-notify-interval {

      &nbs= p;   type uint32 {

      &nbs= p;     range "1 .. 3600";

      &nbs= p;   }

      &nbs= p;   must '. >=3D ../../min-config-values/telemetry-notify-int= erval' {

      &nbs= p;     error-message

      &nbs= p;       "The value must be greater than= or equal

      &nbs= p;        to the telemetry-notify-interv= al in the min-config-values";

      &nbs= p;   }

      &nbs= p;   units "seconds";

      &nbs= p;   description

      &nbs= p;     "Minimum number of seconds between successi= ve

      &nbs= p;      telemetry notifications.";=

      &nbs= p; }

=3D=3D=3D

 

We can make the text c= lear:

 

OLD: 

   DOTS agents MUST NOT send pre-or-ongoing=
-mitigation telemetry
   messages to the same peer more frequently tha=
n once every 'telemetry-
   notify-interval' (Section 6.1).&nbs=
p; If a telemetry notification is sent
   using a block-like transfer mechanism (e.g.,<=
o:p>
   [I-D=
.bosh-core-new-block]), this rate limit policy MUST NOT consider
   these individual blocks as separate notificat=
ions, but as a single
   notification.

 

NEW:= 

   DOTS agents MUST NOT send pre-or-ongoing-miti=
gation telemetry
   notifications to the same peer more frequentl=
y than once every 'telemetry-
   notify-interval' (Section 6.1).&nbs=
p; If a telemetry notification is sent
   using a block-like transfer mechanism (e.g.,<=
o:p>
   [I-D=
.bosh-core-new-block]), this rate limit policy MUST NOT consider
   these individual blocks as separate notificat=
ions, but as a single
   notification.

 

Jon>= This change works for me.

 

2)

Use of multiple Uri-Query:=

 

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: target_prefix=3D[2.3= ..4.5]

I think this should be OR<= /o:p>

[Med] Yes, this is the= same interpretation when we include target-prefix in the message body.

 

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: target_port=3D[80]

I think this should be an AND.<= o:p>

[Med] Yes, because the= target-port is specifying a subset of ports bound to the target-prefix. &n= bsp;

 

Perhaps we should have operator= queries

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: op=3DOR

Uri-Query: target_prefix=3D[2.3= ..4.5]

 

Uri-Query: target_prefix=3D[1.2= ..3.4]

Uri-Query: op=3DAND<= /span>

Uri-Query: target_port=3D[80]

[Med] I don’t th= ink this is needed. We don’t specify the operator when we include the= target clauses in the message body. The same rules apply. We can clarify this in the text If you think this is needed.  

 

Jon>= I think that it is worth stating that the same rules apply for clarificati= on.

 

Thoughts?

 

3)

What happens if a Query cannot = be supported.

 

E.g. Uri-Query: target_port=3D[= 80] and statistics on the server by a port basis  is not supported.&nb= sp; Do we want to either error out with a 4.0X responses, or should we incl= ude a (new additional) YANG body response indicating which Uri-Query is not supported?

&n= bsp;

[Med] Good point. The = client can retrieve during telemetry setup the supported query types + = server replies with 4.00 when an invalid query type is used.

&n= bsp;

Jon>= I think the server stating what Queries are supported is a good idea.=

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93303149B39COPEXCAUBMA2corp_-- From nobody Tue Apr 21 03:56: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 57DC53A0835 for ; Tue, 21 Apr 2020 03:56:36 -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 Q0oFHTp7Vtc7 for ; Tue, 21 Apr 2020 03:56:33 -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 1254C3A082C for ; Tue, 21 Apr 2020 03:56: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 1jQqZo-0003M8-7k; Tue, 21 Apr 2020 11:56:28 +0100 From: "Jon Shallow" To: , References: <102501d6170c$2be45900$83ad0b00$@jpshallow.com> <787AE7BB302AE849A7480A190F8B933031499776@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <105901d6171a$1a132860$4e397920$@jpshallow.com> <114601d617bb$21c1cac0$65456040$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303149B39C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149B39C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 21 Apr 2020 11:56:21 +0100 Message-ID: <118601d617cb$7e394250$7aabc6f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1187_01D617D3.E0023E30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIP9ThI7DkLoYVsg/jsxFxzT+JmLAHYmGmaAtdF3C8CKMkxNwGSYnaRp8xQ6fA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 10:56:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1187_01D617D3.E0023E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline. =20 Regards =20 Jon =20 From: Dots [mailto: -dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 April 2020 11:04 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi Jon, =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 21 avril 2020 10:59 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi all, =20 A further thought on the use of Uri-Queries to clarify the AND/OR usage. =20 If you only allow one query per query type and put the match list in an array, then this will be an OR of the array list (the same as we do for = the target* definitions right now. E.G. :- =20 Uri-Query: target_prefix=3D[1.2.3.4/32,4.3.2.1/32] Gives either 1.2.3.4 or 4.3.2.1 as a valid match. =20 And=20 Uri-Query: target-prefix=3D[1.2.3.4/32,4.3.2.1/32] Uri-Query: lower-port=3D[80,443] Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443) =20 [] should not include spaces and comma used as a separator. =20 [Med] The issue I have with this is that we will need to handle cases = where both lower-port and upper-port are present. Not sure what would be the benefit of allowing multiple key values, compact uris? If that=92s a = concern, we may consider shortened names in the query (e.g., s/target-prefix/tp, s/lower-port/lp, ..). Jon> fair point about lower and upper ports. Uri-Query: target-port[80-85,443] works for me and covers both ranges and = individual ports. =20 Jon> As this would be options on a GET request that has no body data, I don=92t think that I am too worried about using shortened names at this = point. =20 Not sure about :- If [] are not used, then it should be treated as a = single item to match. =20 The list of valid Uri-Queries may need to be extended. =20 A Uri-Query option can include the following parameters: target-prefix, lower-port, upper-port, target-protocol, target-fqdn, target-uri, alias-name. =20 should include mid and content (=91c=92).=20 [Med] OK. Please note that =91c=92 wasn=92t listed because we do have = the following: =20 The DOTS server follows the same considerations discussed in Section of 4.5.3 of [I-D.ietf-dots-signal-channel] for managing DOTS telemetry configuration freshness and notification. Likewise, a DOTS client may control the selection of configuration and non- configuration data nodes when sending a GET request by means of the 'c' Uri-Query option and following the procedure specified in Section of 4.4.2 of [I-D.ietf-dots-signal-channel]. These considerations are not re-iterated in the following sections. =20 I added a pointer to that section. =20 Do we need to be able to filter on source attributes as well? [Med] What would be the usage? Is it the case of an administrator that = is aware (using some means) that some sources are involved an attacks on = other networks, then sends a request to its server to filter telemetry data = bound to these source? Filtering in this case may be problematic as some = attacks may be observed but are hidden by the filter on the source. Or do we = want to focus on very few talkers? For example, the client would instruct the = server to send data only related to the top-talker, 3 first top-talkers, etc.?=20 =20 Jon> Source-port=3D could be useful =96 especially when being subjected = to a reflected type attach where all the traffic is coming from, say, source = port 53 =20 Jon> Otherwise, it may help to filter on top-talkers, vendor specific = attack types etc. =20 Jon> Which then leads me on to something else. If we asking for = telemetry for 2 (or more) different target IPs and the server is returning vendor specific attack details. For attack-detail, keyed by attack-id, if the = same attack is hitting more than 1 target IP, can I display this information = per IP or does it have to be aggregated? =20 ~Jon =20 Regards =20 Jon =20 =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 20 April 2020 14:47 To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi Med, =20 See inline. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of iemohamed.boucadair@orange.com Sent: 20 April 2020 13:54 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi Jon,=20 =20 Thank you for sharing the comments.=20 =20 Please see =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 20 avril 2020 14:07 =C0 : dots@ietf.org Objet : [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi All, =20 1) DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1). =20 If I do a PUT /tm-setup, followed immediately by a GET /tm-setup, should = the GET fail based on the telemetry-notify-interval, or should telemetry-notify-interval apply individually to PUT. GET and DELETE? [I may want to do a DELETE (no tsid) followed by a GET to get suitable max/min information and telemetry-notify-interval can easily be more = than 1 second. ] =20 [Med] This rate limit does not apply to these messages; it applies only = for notifications;=20 =20 =3D=3D leaf telemetry-notify-interval { type uint32 { range "1 .. 3600"; } must '. >=3D = ../../min-config-values/telemetry-notify-interval' { error-message "The value must be greater than or equal to the telemetry-notify-interval in the = min-config-values"; } units "seconds"; description "Minimum number of seconds between successive telemetry notifications."; } =3D=3D=3D =20 We can make the text clear:=20 =20 OLD:=20 DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry messages to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1 = ). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D..bosh-core-new-block ]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. =20 NEW: DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetry- notify-interval' (Section 6.1 = ). If a telemetry notification is sent using a block-like transfer mechanism (e.g., [I-D..bosh-core-new-block ]), this rate limit policy MUST NOT consider these individual blocks as separate notifications, but as a single notification. =20 Jon> This change works for me. =20 2) Use of multiple Uri-Query: =20 Uri-Query: target_prefix=3D[1.2...3.4] Uri-Query: target_prefix=3D[2.3...4.5] I think this should be OR [Med] Yes, this is the same interpretation when we include target-prefix = in the message body. =20 Uri-Query: target_prefix=3D[1.2...3.4] Uri-Query: target_port=3D[80] I think this should be an AND. [Med] Yes, because the target-port is specifying a subset of ports bound = to the target-prefix. =20 =20 Perhaps we should have operator queries Uri-Query: target_prefix=3D[1.2...3.4] Uri-Query: op=3DOR Uri-Query: target_prefix=3D[2.3...4.5] =20 Uri-Query: target_prefix=3D[1.2...3.4] Uri-Query: op=3DAND Uri-Query: target_port=3D[80] [Med] I don=92t think this is needed. We don=92t specify the operator = when we include the target clauses in the message body. The same rules apply. We = can clarify this in the text If you think this is needed. =20 =20 Jon> I think that it is worth stating that the same rules apply for clarification.=20 =20 Thoughts? =20 3) What happens if a Query cannot be supported. =20 E.g. Uri-Query: target_port=3D[80] and statistics on the server by a = port basis is not supported. Do we want to either error out with a 4.0X responses, or should we include a (new additional) YANG body response indicating which Uri-Query is not supported? =20 [Med] Good point. The client can retrieve during telemetry setup the supported query types + server replies with 4.00 when an invalid query = type is used.=20 =20 Jon> I think the server stating what Queries are supported is a good = idea. =20 Regards =20 Jon ------=_NextPart_000_1187_01D617D3.E0023E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please see inline.

 

Regards

 

Jon

 

From:= Dots = [mailto: -dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 21 April 2020 = 11:04
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS telemetry Issues picked up in Interop = Testing

 

Hi = Jon,

 

Please see inline.

 

Cheers,

Med

 

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

 

Hi = all,

 

A further thought on the = use of Uri-Queries to clarify the AND/OR usage.

 

If you only allow one = query per query type and put the match list in an array, then this will = be an OR of the array list (the same as we do for the target* = definitions right now.  E.G. :-

 

Uri-Query: = target_prefix=3D[1.2.3.4/32,4.3.2.1/32]

Gives either 1.2.3.4 or = 4.3.2.1 as a valid match.

 

And =

Uri-Query: = target-prefix=3D[1.2.3.4/32,4.3.2.1/32]

Uri-Query: = lower-port=3D[80,443]

Gives (either 1.2.3.4 or 4.3.2.1) and (either = port 80 or 443)

 

[] should not include = spaces and comma used as a separator.

 

[Med] The issue I have with this is that we will = need to handle cases where both lower-port and upper-port are present. = Not sure what would be the benefit of allowing multiple key values, = compact uris? If that’s a concern, we may consider shortened names = in the query (e.g., s/target-prefix/tp, s/lower-port/lp, = ..).

Jon> fair point about lower and upper ports.=A0 = Uri-Query: target-port[80-85,443] works for me and covers both ranges = and individual ports.

 

Jon> As this would be = options on a GET request that has no body data, I don’t think that = I am too worried about using shortened names at this = point.

 

Not sure about :-  = If [] are not used, then it should be treated as a single item to = match.

 

The list of valid = Uri-Queries may need to be extended.

 

A Uri-Query option can = include the following

   parameters: target-prefix, = lower-port, upper-port, target-protocol,

   = target-fqdn, target-uri, alias-name.

 

should include mid and = content (‘c’). 

[Med] OK. Please note that ‘c’ = wasn’t listed because we do have the = following:

 

  The DOTS = server follows the same considerations discussed = in

   = Section of 4.5.3 of [I-D.ietf-dots-signal-channel] for managing = DOTS

   = telemetry configuration freshness and notification.  Likewise, a = DOTS

   client = may control the selection of configuration and = non-

   = configuration data nodes when sending a GET request by means of = the

   'c' = Uri-Query option and following the procedure specified = in

   = Section of 4.4.2 of [I-D.ietf-dots-signal-channel].  = These

   = considerations are not re-iterated in the following = sections.

 

I added a pointer to that = section.

 

  Do we need to be = able to filter on source attributes as well?

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

 

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

 

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

 

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

 

~Jon

 

Regards

 

Jon

 

 

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: 20 April 2020 14:47
To: = mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: = [Dots] DOTS telemetry Issues picked up in Interop = Testing

 

Hi Med,

 

See = inline.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = iemohamed.boucadair@orange.com
Sent: 20 April 2020 = 13:54
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS telemetry Issues picked up in Interop = Testing

 

Hi Jon, =

 

Thank you for sharing the comments. =

 

Please see

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : lundi 20 avril 2020 = 14:07
=C0 : dots@ietf.org
Objet : [Dots] = DOTS telemetry Issues picked up in Interop = Testing

 

Hi = All,

 

1)

   = DOTS agents MUST NOT send pre-or-ongoing-mitigation = telemetry

   messages to = the same peer more frequently than once every = 'telemetry-

   = notify-interval' (Section 6.1).

 

If I do a = PUT /tm-setup, followed immediately by a GET /tm-setup, should the GET = fail based on the telemetry-notify-interval, or should = telemetry-notify-interval apply individually to PUT. GET and = DELETE?

[I may want to do a DELETE = (no tsid) followed by a GET to get suitable max/min information and = telemetry-notify-interval can easily be more than 1 second. = ]

 

[Med] This rate limit does not apply to these = messages; it applies only for notifications; =

 

=3D=3D

        leaf = telemetry-notify-interval {

          type uint32 = {

            = range "1 .. 3600";

          = }

          must '. = >=3D ../../min-config-values/telemetry-notify-interval' = {

        =     error-message

           &= nbsp;  "The value must be greater than or = equal

           &= nbsp;   to the telemetry-notify-interval in the = min-config-values";

          = }

          units = "seconds";

          = description

            = "Minimum number of seconds between = successive

           &= nbsp; telemetry notifications.";

        = }

=3D=3D=3D

 

We can make the text clear: =

 

OLD: 

   DOTS agents MUST NOT send =
pre-or-ongoing-mitigation telemetry
   messages to the same peer more frequently than once =
every 'telemetry-
   =
notify-interval' (Section 6.1).  If a telemetry notification is =
sent
   using =
a block-like transfer mechanism (e.g.,
   [I-D..bosh-core-new-block]), this rate limit policy =
MUST NOT consider
   these =
individual blocks as separate notifications, but as a =
single
   =
notification.

 

NEW:

   DOTS agents MUST NOT send pre-or-ongoing-mitigation =
telemetry
   =
notifications to the same peer more frequently than once every =
'telemetry-
   =
notify-interval' (Section 6.1).  If a telemetry notification is =
sent
   using =
a block-like transfer mechanism (e.g.,
   [I-D..bosh-core-new-block]), this rate limit policy =
MUST NOT consider
   these =
individual blocks as separate notifications, but as a =
single
   =
notification.

 

Jon> This change = works for me.

 

2)

Use of multiple = Uri-Query:

 

Uri-Query: = target_prefix=3D[1.2...3.4]

Uri-Query: = target_prefix=3D[2.3...4.5]

I think = this should be OR

[Med] Yes, this is the = same interpretation when we include target-prefix in the message = body.

 

Uri-Query: = target_prefix=3D[1.2...3.4]

Uri-Query: target_port=3D[80]

I think this should be an AND.

[Med] Yes, because the target-port is specifying a = subset of ports bound to the target-prefix.  

 

Perhaps we = should have operator queries

Uri-Query: = target_prefix=3D[1.2...3.4]

Uri-Query: op=3DOR

Uri-Query: = target_prefix=3D[2.3...4.5]

 

Uri-Query: = target_prefix=3D[1.2...3.4]

Uri-Query: op=3DAND

Uri-Query: target_port=3D[80]

[Med] I don’t think this is needed. We = don’t specify the operator when we include the target clauses in = the message body. The same rules apply. We can clarify this in the text = If you think this is needed.  

 

Jon> I think that it = is worth stating that the same rules apply for clarification. =

 

Thoughts?

 

3)

What happens if = a Query cannot be supported.

 

E.g. = Uri-Query: target_port=3D[80] and statistics on the server by a port = basis  is not supported.  Do we want to either error out with = a 4.0X responses, or should we include a (new additional) YANG body = response indicating which Uri-Query is not supported?

 

[Med] Good point. The client can retrieve during = telemetry setup the supported query types + server replies with 4.00 = when an invalid query type is used.

 

Jon> I think the = server stating what Queries are supported is a good = idea.

 

Regards

 

Jon

<= /body> ------=_NextPart_000_1187_01D617D3.E0023E30-- From nobody Tue Apr 21 04:09: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 450403A0887 for ; Tue, 21 Apr 2020 04:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB05GhokmRsc for ; Tue, 21 Apr 2020 04:09:41 -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 D03F73A0882 for ; Tue, 21 Apr 2020 04:09:40 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 49616p6nFyz1ySt; Tue, 21 Apr 2020 13:09:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587467379; bh=ZBpFAQ3NXPPL/AH+v75hWe+CPzEw0mzdnzuh/MEJ4vg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=rit7QWyb1GjXL8N4j6eAtpl8RcTu5uN83Y9h9+X7wrjJzO8rmNpEtSoqa57wOh65A QLweAOAtVSVaVDYAHA42lMkWP6zVxeaCfc2+klfQuev2Z7mdGYOnDQmskOP0/BFucj fbDxo7IH14f4FPcLbmesyocRdvn7kAxvawygYZOYNPvsAscwtiZZUDbPZLI122d9GC khc+YKRiSP1dxL719MQKSSWICU4pO4WGdxu9IQRLXw4wq2z0fPxjknraklTj4JuPAu ktqFz/boZSSjanhqK8mNGYQkp3kMcuKou7oVljoEzb539AzVE2YiBuf4CzXnda49ra kxIwpC1Pwxzfg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 49616p5qHZz1xpM; Tue, 21 Apr 2020 13:09:38 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: per target or aggregated ? RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Thread-Index: AdYXzVNYJVRgDrWORXqS2nE1SG7+rg== Date: Tue, 21 Apr 2020 11:09:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149B423@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_787AE7BB302AE849A7480A190F8B93303149B423OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] per target or aggregated ? RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 11:09:45 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149B423OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, This is up to the server. The draft says: A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., 'top-talkers') for all targets of a domain, or when justified, send specific information (e.g., 'top-talkers') per individual targets. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Jon> Which then leads me on to something else. If we asking for telemetry = for 2 (or more) different target IPs and the server is returning vendor spe= cific attack details. For attack-detail, keyed by attack-id, if the same a= ttack is hitting more than 1 target IP, can I display this information per = IP or does it have to be aggregated? --_000_787AE7BB302AE849A7480A190F8B93303149B423OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

This is up to the server. The draft says:

 

   A DOTS server may aggregate= pre-or-ongoing-mitigation data (e.g.,

   'top-talkers') for all targ= ets of a domain, or when justified, send

   specific information (e.g.,= 'top-talkers') per individual targets.

 

Cheers,

Med

 

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

 

&n= bsp;

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

--_000_787AE7BB302AE849A7480A190F8B93303149B423OPEXCAUBMA2corp_-- From nobody Tue Apr 21 04:36:03 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 C9E633A0927 for ; Tue, 21 Apr 2020 04:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PWblrU98eaF for ; Tue, 21 Apr 2020 04:35:58 -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 A2F813A0926 for ; Tue, 21 Apr 2020 04:35:57 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4961j74lNgz1yhR; Tue, 21 Apr 2020 13:35:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587468955; bh=8TCj797KGy6Ve/qK5L0v/rJRwxr2T+LYw3bd3UNP+JU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=vTYNTKuuohIjqumLlD2VppHV7TJatZjIGLIkSqwShFCYr3tCRNvnrO7Eb1LytlMAw wKqR4xpceU8ft7Sk/5VnMHhfWs/eP8qEccCJ5ho5Hul9JHezKtXlvA4gPOSxAlPsxy dvxQP7oBdtEAqYhsOlkhGiusmKEZ/4R92B9B+AS9bDhE0e5kUKOzUZ/yoUbckNS2Ro jm08pVP7pIBKo6sqNLd3x5nleaOlkEhGO3UVUQqkBwGHFyokOW3go7XrxySPELYiSZ KT05EoPdn3tZfBAj6hlJmMTp5iWoBz5u9o6WREdE5GD24R0jhAm9yEpCWsnj+RI4b+ +FOHjrADnCPkA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4961j73nvSzyQ4; Tue, 21 Apr 2020 13:35:55 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: Filter on source (RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Thread-Index: AdYX0QGiu+NrNjIASrqZ9MOYQ41zKg== Date: Tue, 21 Apr 2020 11:35:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149B4CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303149B4CBOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 11:36:00 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149B4CBOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Why filtering on the source if all the attack traffic is coming from the sa= me port number? I'm nervous about setting a filter that may hide useful attack telemetry (n= ot matching that filter). Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Do we need to be able to filter on source attributes as well? [Med] What would be the usage? Is it the case of an administrator that is a= ware (using some means) that some sources are involved an attacks on other = networks, then sends a request to its server to filter telemetry data bound= to these source? Filtering in this case may be problematic as some attacks= may be observed but are hidden by the filter on the source. Or do we want = to focus on very few talkers? For example, the client would instruct the se= rver to send data only related to the top-talker, 3 first top-talkers, etc.= ? Jon> Source-port=3D could be useful - especially when being subjected to a = reflected type attach where all the traffic is coming from, say, source por= t 53 Jon> Otherwise, it may help to filter on top-talkers, vendor specific attac= k types etc. Jon> Which then leads me on to something else. If we asking for telemetry = for 2 (or more) different target IPs and the server is returning vendor spe= cific attack details. For attack-detail, keyed by attack-id, if the same a= ttack is hitting more than 1 target IP, can I display this information per = IP or does it have to be aggregated? --_000_787AE7BB302AE849A7480A190F8B93303149B4CBOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Why filtering on the source if all the atta= ck traffic is coming from the same port number?

 

I’m nervous about setting a filter th= at may hide useful attack telemetry (not matching that filter).<= /span>

 

Cheers,

Med

 

 

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

 

 

  = Do we need to be able to filter on source attributes as well?

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

 

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

&n= bsp;

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

&n= bsp;

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

 

--_000_787AE7BB302AE849A7480A190F8B93303149B4CBOPEXCAUBMA2corp_-- From nobody Tue Apr 21 07:20: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 AB7233A0CFA for ; Tue, 21 Apr 2020 07:20: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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv5jpnD2DA4w for ; Tue, 21 Apr 2020 07:20:15 -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 CF4EA3A0CDE for ; Tue, 21 Apr 2020 07:20:12 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4965LX2Wv1z8tMk; Tue, 21 Apr 2020 16:20:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587478804; bh=l3UYv9HKpLGzLZfOrAibpRVCdhNN4VrAHLpT0li7lPk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=qgD7n7NLUrnKt1HDce6HqKAsd0lMWOkF0xlPHxEMIAUTZKWozqnMHRfx5J0rQ8Kjo HojpT/WqvK4iVso3F8kOqQqcNVjqYjcnY/1UG3OlHtfijzmtwGxNasWASgYljbzoJK BFjb77RC2DomnWyI25mkrU4FDpLGYEj4uxYYS9I6xLDLmSfD3+11a8Rh9GWs3w8ziO T5hqeVrAHcLKAlJlo2oLkcsIdL/hCs7QwlRcXMY838ChijVANRtpNC6xNLloSXXy0J tRHdlDI9qQN7ck5oCkKtC17CJ1RgEziqYjwDf8oHNQrt+OkPn823N5g4XmA36+PGA8 tTWGh7u2V0brg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4965LX1ZCcz5vNf; Tue, 21 Apr 2020 16:20:04 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: multiple values in the filter RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Thread-Index: AdYX5/ARm/QK3l+oTTyHOC5b9Xhf1Q== Date: Tue, 21 Apr 2020 14:20:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149B679@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_787AE7BB302AE849A7480A190F8B93303149B679OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 14:20:22 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149B679OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, If we want to allow for multiple values to be included, all what we need is= to agree on the separator to be used for ranges and for distinct elements.= We can get rid of []. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 10:59 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi all, A further thought on the use of Uri-Queries to clarify the AND/OR usage. If you only allow one query per query type and put the match list in an arr= ay, then this will be an OR of the array list (the same as we do for the ta= rget* definitions right now. E.G. :- Uri-Query: target_prefix=3D[1.2.3.4/32,4.3.2.1/32] Gives either 1.2.3.4 or 4.3.2.1 as a valid match. And Uri-Query: target-prefix=3D[1.2.3.4/32,4.3.2.1/32] Uri-Query: lower-port=3D[80,443] Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443) [] should not include spaces and comma used as a separator. [Med] The issue I have with this is that we will need to handle cases where= both lower-port and upper-port are present. Not sure what would be the ben= efit of allowing multiple key values, compact uris? If that's a concern, we= may consider shortened names in the query (e.g., s/target-prefix/tp, s/low= er-port/lp, ..). Jon> fair point about lower and upper ports. Uri-Query: target-port[80-85,= 443] works for me and covers both ranges and individual ports. Jon> As this would be options on a GET request that has no body data, I don= 't think that I am too worried about using shortened names at this point. --_000_787AE7BB302AE849A7480A190F8B93303149B679OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

If we want to allow for multiple values to = be included, all what we need is to agree on the separator to be used for r= anges and for distinct elements. We can get rid of [].

 

Cheers,

Med

 

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

 

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 21 avril 2020 10:59
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop T= esting

 

Hi all,=

&n= bsp;

A furth= er thought on the use of Uri-Queries to clarify the AND/OR usage.

&n= bsp;

If you = only allow one query per query type and put the match list in an array, the= n this will be an OR of the array list (the same as we do for the target* d= efinitions right now.  E.G. :-

&n= bsp;

Uri-Que= ry: target_prefix=3D[1.2.3.4/32,4.3.2.1/32]

Gives e= ither 1.2.3.4 or 4.3.2.1 as a valid match.

&n= bsp;

And

Uri-Que= ry: target-prefix=3D[1.2.3.4/32,4.3.2.1/32]

Uri-Que= ry: lower-port=3D[80,443]

Gives (= either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443)

&n= bsp;

[] shou= ld not include spaces and comma used as a separator.

&n= bsp;

[Med] The issue I have= with this is that we will need to handle cases where both lower-port and u= pper-port are present. Not sure what would be the benefit of allowing multiple key values, compact uris? If that’s a concern, = we may consider shortened names in the query (e.g., s/target-prefix/tp, s/l= ower-port/lp, ..).

 

Jon> fair point about low= er and upper ports.  Uri-Query: target-port[80-85,443] works for me an= d covers both ranges and individual ports.

&n= bsp;

Jon>= As this would be options on a GET request that has no body data, I donR= 17;t think that I am too worried about using shortened names at this point.=

&n= bsp;

 

--_000_787AE7BB302AE849A7480A190F8B93303149B679OPEXCAUBMA2corp_-- From nobody Tue Apr 21 07:25: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 66A3F3A0D12 for ; Tue, 21 Apr 2020 07:25:46 -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 o_BDNAnWNS0t for ; Tue, 21 Apr 2020 07:25:38 -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 977643A0D2A for ; Tue, 21 Apr 2020 07:25: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 1jQtpy-0003Uz-U6; Tue, 21 Apr 2020 15:25:23 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303149B679@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149B679@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 21 Apr 2020 15:25:16 +0100 Message-ID: <120701d617e8$ad6a1370$083e3a50$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1208_01D617F1.0F2E7B70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLXo3sU9r4cWwKI1jsej+w/E829yqaAicSA Content-Language: en-gb Archived-At: Subject: Re: [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 14:25:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1208_01D617F1.0F2E7B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For me, - (minus) is for a range and , (comma) for distinct elements. Spaces not allowed. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 April 2020 15:20 To: Jon Shallow; dots@ietf.org Subject: [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing =20 Re-,=20 =20 If we want to allow for multiple values to be included, all what we need = is to agree on the separator to be used for ranges and for distinct = elements. We can get rid of []. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 21 avril 2020 10:59 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi all, =20 A further thought on the use of Uri-Queries to clarify the AND/OR usage. =20 If you only allow one query per query type and put the match list in an array, then this will be an OR of the array list (the same as we do for = the target* definitions right now. E.G. :- =20 Uri-Query: target_prefix=3D[1.2.3.4/32,4.3.2.1/32] Gives either 1.2.3.4 or 4.3.2.1 as a valid match. =20 And=20 Uri-Query: target-prefix=3D[1.2.3.4/32,4.3.2.1/32] Uri-Query: lower-port=3D[80,443] Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443) =20 [] should not include spaces and comma used as a separator. =20 [Med] The issue I have with this is that we will need to handle cases = where both lower-port and upper-port are present. Not sure what would be the benefit of allowing multiple key values, compact uris? If that=92s a = concern, we may consider shortened names in the query (e.g., s/target-prefix/tp, s/lower-port/lp, ..). =20 Jon> fair point about lower and upper ports. Uri-Query: target-port[80-85,443] works for me and covers both ranges and = individual ports. =20 Jon> As this would be options on a GET request that has no body data, I don=92t think that I am too worried about using shortened names at this = point. =20 =20 ------=_NextPart_000_1208_01D617F1.0F2E7B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For me, - (minus) is for a range and , (comma) = for distinct elements.=A0 Spaces not allowed.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 21 April 2020 = 15:20
To: Jon Shallow; dots@ietf.org
Subject: [Dots] = multiple values in the filter RE: DOTS telemetry Issues picked up in = Interop Testing

 

Re-, =

 

If we want to allow for multiple values to be = included, all what we need is to agree on the separator to be used for = ranges and for distinct elements. We can get rid of = [].

 

Cheers,

Med

 

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

 

 

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

 

Hi = all,

 

A further thought on the = use of Uri-Queries to clarify the AND/OR usage.

 

If you only allow one = query per query type and put the match list in an array, then this will = be an OR of the array list (the same as we do for the target* = definitions right now.  E.G. :-

 

Uri-Query: = target_prefix=3D[1.2.3.4/32,4.3.2.1/32]

Gives either 1.2.3.4 or = 4.3.2.1 as a valid match.

 

And =

Uri-Query: = target-prefix=3D[1.2.3.4/32,4.3.2.1/32]

Uri-Query: = lower-port=3D[80,443]

Gives (either 1.2.3.4 or 4.3.2.1) and (either = port 80 or 443)

 

[] should not include = spaces and comma used as a separator.

 

[Med] The issue I have with this is that we will = need to handle cases where both lower-port and upper-port are present. = Not sure what would be the benefit of allowing multiple key values, = compact uris? If that’s a concern, we may consider shortened names = in the query (e.g., s/target-prefix/tp, s/lower-port/lp, = ..).

 

Jon> fair point about lower and upper = ports.  Uri-Query: target-port[80-85,443] works for me and covers = both ranges and individual ports.

 

Jon> As this would be = options on a GET request that has no body data, I don’t think that = I am too worried about using shortened names at this = point.

 

 

------=_NextPart_000_1208_01D617F1.0F2E7B70-- From nobody Wed Apr 22 02:04:09 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 F2C683A0BEC for ; Wed, 22 Apr 2020 02:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WujyQdjJ8uVf for ; Wed, 22 Apr 2020 02:04:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B073A0BEA for ; Wed, 22 Apr 2020 02:04:05 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 496ZHR2NLgz2xlP; Wed, 22 Apr 2020 11:04:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587546243; bh=r8cKKDMZ+FtrZ4rsGFfCQAyoQDSDfewbFKyu15dcm70=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=OP2HiwX2kBPASuaOqKuZtOvdxlNizXePnz95PERr3zX0lRq0h8JacfoqocpB5ssK7 WroPHSTNtxt/+dXA+y85BMAk5IqqI2I7R4Eu5zJIbaf1s7w2v9NO7v8cjg2wtPHVrg gPql0LC4PZtfPsxS8apy9TSt+lnXtk7NB9sjBoHI9uuxb4EBfAXSsLAvJ979bLUOyq VCXOESk019n0Dg7HPYJk4N+UjM1fOlyCl71Od8sESWnetsJqZ5dw6JCQV+4UyEiJsz GREesVMtgLYBFPHrT7/gA/Auwy5vP8MTjrrO6UjhVS7aTuuey1Ehq9+ja8wIoxm4f9 inamJg/68h+aw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 496ZHR1RdVz5vNn; Wed, 22 Apr 2020 11:04:03 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing Thread-Index: AdYX0QGihtMaUguYXUgw3qxX+TclMAAs9JbA Date: Wed, 22 Apr 2020 09:04:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149C253@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303149B4CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149B4CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303149C253OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 09:04:07 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149C253OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Here is a text proposal with a warning about the use of these filters: DOTS clients may also filter out the asynchronous notifications from the DOTS server by indicating a specific source information. To that aim, a DOTS client may include source-prefix, source-port, or source- icmp-type in an Uri-Query option. The same considerations (ranges, multiple values) specified for target clauses apply for source clauses. Special care SHOULD be taken when using these filters as some attacks may be hidden to the requesting DOTS client (e.g., the attack changes its source information). Do we need to say more? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : mardi 21 avril 2020 13:36 =C0 : Jon Shallow; dots@ietf.org Objet : [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Int= erop Testing Re-, Why filtering on the source if all the attack traffic is coming from the sa= me port number? I'm nervous about setting a filter that may hide useful attack telemetry (n= ot matching that filter). Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Do we need to be able to filter on source attributes as well? [Med] What would be the usage? Is it the case of an administrator that is a= ware (using some means) that some sources are involved an attacks on other = networks, then sends a request to its server to filter telemetry data bound= to these source? Filtering in this case may be problematic as some attacks= may be observed but are hidden by the filter on the source. Or do we want = to focus on very few talkers? For example, the client would instruct the se= rver to send data only related to the top-talker, 3 first top-talkers, etc.= ? Jon> Source-port=3D could be useful - especially when being subjected to a = reflected type attach where all the traffic is coming from, say, source por= t 53 Jon> Otherwise, it may help to filter on top-talkers, vendor specific attac= k types etc. Jon> Which then leads me on to something else. If we asking for telemetry = for 2 (or more) different target IPs and the server is returning vendor spe= cific attack details. For attack-detail, keyed by attack-id, if the same a= ttack is hitting more than 1 target IP, can I display this information per = IP or does it have to be aggregated? --_000_787AE7BB302AE849A7480A190F8B93303149C253OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

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

 

   DOTS clients may also filter out the asynchro= nous notifications from

   the DOTS server by indicating a specific sour= ce information.  To that

   aim, a DOTS client may include source-prefix,= source-port, or source-

   icmp-type in an Uri-Query option.  The s= ame considerations (ranges,

   multiple values) specified for target clauses= apply for source

   clauses.  Special care SHOULD be taken w= hen using these filters as

   some attacks may be hidden to the requesting = DOTS client (e.g., the

   attack changes its source information).<= /o:p>

 

Do we need to say more?

 

Cheers,

Med

 

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

 

Re-,

 

Why filtering on the source if all the attack traffic is comi= ng from the same port number?

 

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

 

Cheers,

Med

 

 

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

 

 

  = Do we need to be able to filter on source attributes as well?

[Med] What would be the usage? Is it the= case of an administrator that is aware (using some means) that some source= s are involved an attacks on other networks, then sends a request to its server to filter telemetry data bound to these sour= ce? Filtering in this case may be problematic as some attacks may be observ= ed but are hidden by the filter on the source. Or do we want to focus on ve= ry few talkers? For example, the client would instruct the server to send data only related to the top-talk= er, 3 first top-talkers, etc.?

 

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

&n= bsp;

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

&n= bsp;

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

 

--_000_787AE7BB302AE849A7480A190F8B93303149C253OPEXCAUBMA2corp_-- From nobody Wed Apr 22 02:08: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 1E2EE3A0C08 for ; Wed, 22 Apr 2020 02:08: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 uKNPIAwjcwvr for ; Wed, 22 Apr 2020 02:08:41 -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 18FFC3A0C02 for ; Wed, 22 Apr 2020 02:08:40 -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 1jRBMx-0004Oe-Nh; Wed, 22 Apr 2020 10:08:35 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303149B4CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303149C253@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149C253@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 22 Apr 2020 10:08:44 +0100 Message-ID: <007301d61885$9fbb0840$df3118c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01D6188E.0180F6E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFr7TwThtMaUguYXUgw3qxX+TclMAGTKlbxqUyXEIA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 09:08:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0074_01D6188E.0180F6E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 The suggested text works for me. =20 The list of valid supported queries need to be updated as well. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 22 April 2020 10:04 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Filter on source (RE: DOTS telemetry Issues picked = up in Interop Testing =20 Hi Jon,=20 =20 Here is a text proposal with a warning about the use of these filters:=20 =20 DOTS clients may also filter out the asynchronous notifications from the DOTS server by indicating a specific source information. To that aim, a DOTS client may include source-prefix, source-port, or source- icmp-type in an Uri-Query option. The same considerations (ranges, multiple values) specified for target clauses apply for source clauses. Special care SHOULD be taken when using these filters as some attacks may be hidden to the requesting DOTS client (e.g., the attack changes its source information). =20 Do we need to say more? =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : mardi 21 avril 2020 13:36 =C0 : Jon Shallow; dots@ietf.org Objet : [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing =20 Re-,=20 =20 Why filtering on the source if all the attack traffic is coming from the same port number? =20 I=92m nervous about setting a filter that may hide useful attack = telemetry (not matching that filter). =20 Cheers, Med =20 =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 =20 Do we need to be able to filter on source attributes as well? [Med] What would be the usage? Is it the case of an administrator that = is aware (using some means) that some sources are involved an attacks on = other networks, then sends a request to its server to filter telemetry data = bound to these source? Filtering in this case may be problematic as some = attacks may be observed but are hidden by the filter on the source. Or do we = want to focus on very few talkers? For example, the client would instruct the = server to send data only related to the top-talker, 3 first top-talkers, etc.?=20 =20 Jon> Source-port=3D could be useful =96 especially when being subjected = to a reflected type attach where all the traffic is coming from, say, source = port 53 =20 Jon> Otherwise, it may help to filter on top-talkers, vendor specific = attack types etc. =20 Jon> Which then leads me on to something else. If we asking for = telemetry for 2 (or more) different target IPs and the server is returning vendor specific attack details. For attack-detail, keyed by attack-id, if the = same attack is hitting more than 1 target IP, can I display this information = per IP or does it have to be aggregated? =20 ------=_NextPart_000_0074_01D6188E.0180F6E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

The suggested text works = for me.

 

The list of valid = supported queries need to be updated as well.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 22 April 2020 = 10:04
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop = Testing

 

Hi Jon, =

 

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

 

   DOTS = clients may also filter out the asynchronous notifications = from

   the = DOTS server by indicating a specific source information.  To = that

   aim, a = DOTS client may include source-prefix, source-port, or = source-

   = icmp-type in an Uri-Query option.  The same considerations = (ranges,

   = multiple values) specified for target clauses apply for = source

   = clauses.  Special care SHOULD be taken when using these filters = as

   some = attacks may be hidden to the requesting DOTS client (e.g., = the

   attack = changes its source information).

 

Do we need to say more?

 

Cheers,

Med

 

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

 

Re-, =

 

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

 

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

 

Cheers,

Med

 

 

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

 

 

  Do we need to be = able to filter on source attributes as well?

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

 

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

 

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

 

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

 

------=_NextPart_000_0074_01D6188E.0180F6E0-- From nobody Wed Apr 22 02:17: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 290213A0C3F for ; Wed, 22 Apr 2020 02:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxlOyFtUv4v2 for ; Wed, 22 Apr 2020 02:17:34 -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 B15303A0C3E for ; Wed, 22 Apr 2020 02:17:33 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 496ZZz1s47z5w9P; Wed, 22 Apr 2020 11:17:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587547051; bh=zC7q58YqgdMt8ZHMstNNjNG8qp+ZkYmIWnyHKT4cIe0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=OxadG3BVRy7cU1WLiBrPzuxERoFwS77+KMCuNDruut5EIkdDN0cteDFn174O+R2qD BfOH9TSsQr3S9hdcageIkiQI1m7iLDI0yt7sTeAvMbZo9PYIU4B7caDeTZ/efWHH+n PlgWQN3V643Rv4in52A281uCPnAp7MhKdab4qmxP+vgWrMJhrK4Bqgr/UTACz0RvMc wP5b3q1kGJnYRM+VCI1ij33H+gDWuSn2ASB8kChgbo3cYXYyRCKDnEXubqMZopBVq1 HYc+SH3k48DdCQJf0+S1W0BoCyxI8c/tKPKYV9bCCwKBSRPz0gj5Jy4kLQE0u7qNJD buCrv+2UU/Otw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 496ZZw2h94zFpWV; Wed, 22 Apr 2020 11:17:28 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing Thread-Index: AQFr7TwThtMaUguYXUgw3qxX+TclMAGTKlbxqUyXEICAAAKrkA== Date: Wed, 22 Apr 2020 09:17:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149C29D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303149B4CB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303149C253@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <007301d61885$9fbb0840$df3118c0$@jpshallow.com> In-Reply-To: <007301d61885$9fbb0840$df3118c0$@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_787AE7BB302AE849A7480A190F8B93303149C29DOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 09:17:36 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149C29DOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Indeed. I have already done that in my local copy. Thanks. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 22 avril 2020 11:09 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Filter on source (RE: DOTS telemetry Issues picked up in= Interop Testing Hi Med, The suggested text works for me. The list of valid supported queries need to be updated as well. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 22 April 2020 10:04 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Filter on source (RE: DOTS telemetry Issues picked up i= n Interop Testing Hi Jon, Here is a text proposal with a warning about the use of these filters: DOTS clients may also filter out the asynchronous notifications from the DOTS server by indicating a specific source information. To that aim, a DOTS client may include source-prefix, source-port, or source- icmp-type in an Uri-Query option. The same considerations (ranges, multiple values) specified for target clauses apply for source clauses. Special care SHOULD be taken when using these filters as some attacks may be hidden to the requesting DOTS client (e.g., the attack changes its source information). Do we need to say more? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : mardi 21 avril 2020 13:36 =C0 : Jon Shallow; dots@ietf.org Objet : [Dots] Filter on source (RE: DOTS telemetry Issues picked up in Int= erop Testing Re-, Why filtering on the source if all the attack traffic is coming from the sa= me port number? I'm nervous about setting a filter that may hide useful attack telemetry (n= ot matching that filter). Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Do we need to be able to filter on source attributes as well? [Med] What would be the usage? Is it the case of an administrator that is a= ware (using some means) that some sources are involved an attacks on other = networks, then sends a request to its server to filter telemetry data bound= to these source? Filtering in this case may be problematic as some attacks= may be observed but are hidden by the filter on the source. Or do we want = to focus on very few talkers? For example, the client would instruct the se= rver to send data only related to the top-talker, 3 first top-talkers, etc.= ? Jon> Source-port=3D could be useful - especially when being subjected to a = reflected type attach where all the traffic is coming from, say, source por= t 53 Jon> Otherwise, it may help to filter on top-talkers, vendor specific attac= k types etc. Jon> Which then leads me on to something else. If we asking for telemetry = for 2 (or more) different target IPs and the server is returning vendor spe= cific attack details. For attack-detail, keyed by attack-id, if the same a= ttack is hitting more than 1 target IP, can I display this information per = IP or does it have to be aggregated? --_000_787AE7BB302AE849A7480A190F8B93303149C29DOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Indeed. I have already done that in my local copy.

 

Thanks.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 22 avril 2020 11:09
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Filter on source (RE: DOTS telemetry Issues = picked up in Interop Testing

 

Hi Med,=

&n= bsp;

The sug= gested text works for me.

&n= bsp;

The lis= t of valid supported queries need to be updated as well.<= /p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 22 April 2020 10:04
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Filter on source (RE: DOTS telemetry Issues pick= ed up in Interop Testing

 

Hi Jon,

 

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

 

   DOTS clients may also filter out the asynchro= nous notifications from

   the DOTS server by indicating a specific sour= ce information.  To that

   aim, a DOTS client may include source-prefix,= source-port, or source-

   icmp-type in an Uri-Query option.  The s= ame considerations (ranges,

   multiple values) specified for target clauses= apply for source

   clauses.  Special care SHOULD be taken w= hen using these filters as

   some attacks may be hidden to the requesting = DOTS client (e.g., the

   attack changes its source information).<= /o:p>

 

Do we need to say more?

 

Cheers,

Med

 

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

 

Re-,

 

Why filtering on the source if all the attack traffic is comi= ng from the same port number?

 

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

 

Cheers,

Med

 

 

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

 

 

  = Do we need to be able to filter on source attributes as well?

[Med] What would be the usage? Is it the= case of an administrator that is aware (using some means) that some source= s are involved an attacks on other networks, then sends a request to its server to filter telemetry data bound to these sour= ce? Filtering in this case may be problematic as some attacks may be observ= ed but are hidden by the filter on the source. Or do we want to focus on ve= ry few talkers? For example, the client would instruct the server to send data only related to the top-talk= er, 3 first top-talkers, etc.?

 

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

&n= bsp;

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

&n= bsp;

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

 

--_000_787AE7BB302AE849A7480A190F8B93303149C29DOPEXCAUBMA2corp_-- From nobody Wed Apr 22 02:26: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 42DD33A0C56 for ; Wed, 22 Apr 2020 02:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ91v7znXnNx for ; Wed, 22 Apr 2020 02:26:17 -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 C47D53A0C54 for ; Wed, 22 Apr 2020 02:26:16 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 496Zn30Dkzz2xRc; Wed, 22 Apr 2020 11:26:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587547575; bh=jCUmGq5G8wgqlE+U/zA8XZU64Q7DC4/B5iI7jt3ydSU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=cUNXfSEKumCwa68meXH/XFTCGP5YJXsDRwXUKxAklOzzAMdAZ7uBpMNTXGgyO6iPc 7qcwiQ7OePeptNAQqOua5jgplphMhEGnZD99M1M9akQUfSDgN3iDek83DtGDl9qxV+ 9Wi45T/jxzb6c3hgCy/mAzaFK0pRKK+kUDztfalGmCrdiz+2sNgYsukke+sYK3q9lh Bh0XcHl12sy2Jfk8q/moy1YcUj97ofqsn9etP0U0kL/RQzJOdfse0lAMbGJG5fojir 6+Nd9VysbHZ3Z6f4pnD8zHYehb4/0WNT1XkEPisiohtfqB/PqxS69syqQKXrac/c0y 504R8PFZvzVZw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 496Zn24zkvzBrLR; Wed, 22 Apr 2020 11:26:14 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing Thread-Index: AQLXo3sU9r4cWwKI1jsej+w/E829yqaAicSAgAE/SZA= Date: Wed, 22 Apr 2020 09:26:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149C2C5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303149B679@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <120701d617e8$ad6a1370$083e3a50$@jpshallow.com> In-Reply-To: <120701d617e8$ad6a1370$083e3a50$@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_787AE7BB302AE849A7480A190F8B93303149C2C5OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 09:26:20 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149C2C5OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Below a change proposal to cover the following: =B7 Multiple non-contiguous values =B7 Contiguous blocks =B7 wildcard OLD: The DOTS client can filter out the asynchronous notifications from the DOTS server by indicating one or more Uri-Query options in its GET request. A Uri-Query option can include the following parameters: target-prefix, lower-port, upper-port, target-protocol, target-fqdn, target-uri, alias-name. NEW: The DOTS client can filter out the asynchronous notifications from the DOTS server by indicating one or more Uri-Query options in its GET request. An Uri-Query option can include the following parameters: target-prefix, target-port, target-protocol, target-fqdn, target-uri, alias-name, 'mid', and 'c' (content) (Section 4.4). If more than one Uri-Query option is included in a request, these options are interpreted in the same way as when multiple target clauses are included in a message body. If multiple values of a query parameter are included in an Uri-Query option, these values MUST be separated by a "," character without any spaces. Range values (i.e., contiguous inclusive block) can be included for target- port, target-protocol, and 'mid' parameters by indicating two bound values separated by a "-" character. Wildcard names (i.e., a name with the leftmost label is the "*" character) can be included in target-fqdn or target-uri parameters. For example, "*.example.com" can be included as a value of the target-fqdn parameter in an Uri- Query option. Better? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 16:25 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] multiple values in the filter RE: DOTS telemetry Issues = picked up in Interop Testing For me, - (minus) is for a range and , (comma) for distinct elements. Spac= es not allowed. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 21 April 2020 15:20 To: Jon Shallow; dots@ietf.org Subject: [Dots] multiple values in the filter RE: DOTS telemetry Issues pic= ked up in Interop Testing Re-, If we want to allow for multiple values to be included, all what we need is= to agree on the separator to be used for ranges and for distinct elements.= We can get rid of []. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 21 avril 2020 10:59 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing Hi all, A further thought on the use of Uri-Queries to clarify the AND/OR usage. If you only allow one query per query type and put the match list in an arr= ay, then this will be an OR of the array list (the same as we do for the ta= rget* definitions right now. E.G. :- Uri-Query: target_prefix=3D[1.2.3.4/32,4.3.2.1/32] Gives either 1.2.3.4 or 4.3.2.1 as a valid match. And Uri-Query: target-prefix=3D[1.2.3.4/32,4.3.2.1/32] Uri-Query: lower-port=3D[80,443] Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443) [] should not include spaces and comma used as a separator. [Med] The issue I have with this is that we will need to handle cases where= both lower-port and upper-port are present. Not sure what would be the ben= efit of allowing multiple key values, compact uris? If that's a concern, we= may consider shortened names in the query (e.g., s/target-prefix/tp, s/low= er-port/lp, ..). Jon> fair point about lower and upper ports. Uri-Query: target-port[80-85,= 443] works for me and covers both ranges and individual ports. Jon> As this would be options on a GET request that has no body data, I don= 't think that I am too worried about using shortened names at this point. --_000_787AE7BB302AE849A7480A190F8B93303149C2C5OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Below a change proposal to cover the following:

=B7         Multiple non-contiguous values

=B7         Contiguous blocks

=B7         wildcard

 

OLD:

 

   The DOTS client can filter out the asynchrono= us notifications from

   the DOTS server by indicating one or more Uri= -Query options in its

   GET request.  A Uri-Query option can inc= lude the following

   parameters: target-prefix, lower-port, upper-= port, target-protocol,

   target-fqdn, target-uri, alias-name.

 

NEW:

   The DOTS client can filter out the asynchrono= us notifications from

   the DOTS server by indicating one or more Uri= -Query options in its

   GET request.  An Uri-Query option can in= clude the following

   parameters: target-prefix, target-port, targe= t-protocol, target-fqdn,

   target-uri, alias-name, 'mid', and 'c' (conte= nt) (Section 4.4).  If

   more than one Uri-Query option is included in= a request, these

   options are interpreted in the same way as wh= en multiple target

   clauses are included in a message body. = If multiple values of a

   query parameter are included in an Uri-Query = option, these values

   MUST be separated by a "," characte= r without any spaces.  Range

   values (i.e., contiguous inclusive block) can= be included for target-

   port, target-protocol, and 'mid' parameters b= y indicating two bound

   values separated by a "-" character= .  Wildcard names (i.e., a name

   with the leftmost label is the "*" = character) can be included in

   target-fqdn or target-uri parameters.  F= or example, "*.example.com"

   can be included as a value of the target-fqdn= parameter in an Uri-

   Query option.

 

Better?

 

Cheers,

Med

 

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 21 avril 2020 16:25
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] multiple values in the filter RE: DOTS telem= etry Issues picked up in Interop Testing

 

For me,= - (minus) is for a range and , (comma) for distinct elements.  Spaces= not allowed.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 21 April 2020 15:20
To: Jon Shallow; dots@ietf.org
Subject: [Dots] multiple values in the filter RE: DOTS telemetry Iss= ues picked up in Interop Testing

 

Re-,

 

If we want to allow for multiple values to be included, all w= hat we need is to agree on the separator to be used for ranges and for dist= inct elements. We can get rid of [].

 

Cheers,

Med

 

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

 

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 21 avril 2020 10:59
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop T= esting

 

Hi all,=

&n= bsp;

A furth= er thought on the use of Uri-Queries to clarify the AND/OR usage.

&n= bsp;

If you = only allow one query per query type and put the match list in an array, the= n this will be an OR of the array list (the same as we do for the target* d= efinitions right now.  E.G. :-

&n= bsp;

Uri-Que= ry: target_prefix=3D[1.2.3.4/32,4.3.2.1/32]

Gives e= ither 1.2.3.4 or 4.3.2.1 as a valid match.

&n= bsp;

And

Uri-Que= ry: target-prefix=3D[1.2.3.4/32,4.3.2.1/32]

Uri-Que= ry: lower-port=3D[80,443]

Gives (= either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443)

&n= bsp;

[] shou= ld not include spaces and comma used as a separator.

&n= bsp;

[Med] The issue I have with this is that= we will need to handle cases where both lower-port and upper-port are pres= ent. Not sure what would be the benefit of allowing multiple key values, compact uris? If that’s a concern, we may consi= der shortened names in the query (e.g., s/target-prefix/tp, s/lower-port/lp= , ..).

 

Jon> fair point about lower and upper ports= .  Uri-Query: target-port[80-85,443] works for me and covers both rang= es and individual ports.

&n= bsp;

Jon>= As this would be options on a GET request that has no body data, I donR= 17;t think that I am too worried about using shortened names at this point.=

&n= bsp;

 

--_000_787AE7BB302AE849A7480A190F8B93303149C2C5OPEXCAUBMA2corp_-- From nobody Wed Apr 22 02:32:44 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 B71673A0C72 for ; Wed, 22 Apr 2020 02:32:42 -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 VGXqwYvtiqZm for ; Wed, 22 Apr 2020 02:32:39 -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 9A3143A0C71 for ; Wed, 22 Apr 2020 02:32:39 -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 1jRBkD-0004Qa-J4; Wed, 22 Apr 2020 10:32:37 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93303149B679@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <120701d617e8$ad6a1370$083e3a50$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303149C2C5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149C2C5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 22 Apr 2020 10:32:46 +0100 Message-ID: <00b401d61888$fb228250$f16786f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01D61891.5CE9F790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLXo3sU9r4cWwKI1jsej+w/E829ygG68+wKAnXBTwemYEUzEA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 09:32:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B5_01D61891.5CE9F790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 Thanks =96 this works for me. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 22 April 2020 10:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] multiple values in the filter RE: DOTS telemetry = Issues picked up in Interop Testing =20 Re-, =20 Below a change proposal to cover the following: =B7 Multiple non-contiguous values =B7 Contiguous blocks =B7 wildcard =20 OLD: =20 The DOTS client can filter out the asynchronous notifications from the DOTS server by indicating one or more Uri-Query options in its GET request. A Uri-Query option can include the following parameters: target-prefix, lower-port, upper-port, target-protocol, target-fqdn, target-uri, alias-name.=20 =20 NEW: The DOTS client can filter out the asynchronous notifications from the DOTS server by indicating one or more Uri-Query options in its GET request. An Uri-Query option can include the following parameters: target-prefix, target-port, target-protocol, target-fqdn, target-uri, alias-name, 'mid', and 'c' (content) (Section 4.4). If more than one Uri-Query option is included in a request, these options are interpreted in the same way as when multiple target clauses are included in a message body. If multiple values of a query parameter are included in an Uri-Query option, these values MUST be separated by a "," character without any spaces. Range values (i.e., contiguous inclusive block) can be included for target- port, target-protocol, and 'mid' parameters by indicating two bound values separated by a "-" character.. Wildcard names (i.e., a name with the leftmost label is the "*" character) can be included in target-fqdn or target-uri parameters. For example, "*.example.com" can be included as a value of the target-fqdn parameter in an Uri- Query option. =20 Better? =20 Cheers, Med =20 =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 21 avril 2020 16:25 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] multiple values in the filter RE: DOTS telemetry = Issues picked up in Interop Testing =20 For me, - (minus) is for a range and , (comma) for distinct elements. Spaces not allowed. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 April 2020 15:20 To: Jon Shallow; dots@ietf.org Subject: [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up in Interop Testing =20 Re-,=20 =20 If we want to allow for multiple values to be included, all what we need = is to agree on the separator to be used for ranges and for distinct = elements. We can get rid of []. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 21 avril 2020 12:56 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 21 avril 2020 10:59 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] DOTS telemetry Issues picked up in Interop Testing =20 Hi all, =20 A further thought on the use of Uri-Queries to clarify the AND/OR usage. =20 If you only allow one query per query type and put the match list in an array, then this will be an OR of the array list (the same as we do for = the target* definitions right now. E.G. :- =20 Uri-Query: target_prefix=3D[1.2.3.4/32,4.3.2.1/32] Gives either 1.2.3.4 or 4.3.2.1 as a valid match. =20 And=20 Uri-Query: target-prefix=3D[1.2.3.4/32,4.3.2.1/32] Uri-Query: lower-port=3D[80,443] Gives (either 1.2.3.4 or 4.3.2.1) and (either port 80 or 443) =20 [] should not include spaces and comma used as a separator. =20 [Med] The issue I have with this is that we will need to handle cases = where both lower-port and upper-port are present. Not sure what would be the benefit of allowing multiple key values, compact uris? If that=92s a = concern, we may consider shortened names in the query (e.g., s/target-prefix/tp, s/lower-port/lp, ..). =20 Jon> fair point about lower and upper ports.. Uri-Query: target-port[80-85,443] works for me and covers both ranges and = individual ports. =20 Jon> As this would be options on a GET request that has no body data, I don=92t think that I am too worried about using shortened names at this = point. =20 =20 ------=_NextPart_000_00B5_01D61891.5CE9F790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Thanks – this = works for me.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 22 April 2020 = 10:26
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] multiple values in the filter RE: DOTS telemetry Issues picked up = in Interop Testing

 

Re-,

 

Below a change proposal to cover the = following:

=B7         = Multiple = non-contiguous values

=B7         = Contiguous = blocks

=B7         = wildcard

 

OLD:

 

   The DOTS client can filter out the asynchronous = notifications from

   the DOTS server by indicating one or more Uri-Query = options in its

   GET request.  A Uri-Query option can include the = following

   = parameters: target-prefix, lower-port, upper-port, = target-protocol,

   target-fqdn, target-uri, alias-name. =

 

NEW:

   The DOTS client can filter out the asynchronous = notifications from

   the DOTS server by indicating one or more Uri-Query = options in its

   GET request.  An Uri-Query option can include = the following

   parameters: target-prefix, target-port, = target-protocol, target-fqdn,

   = target-uri, alias-name, 'mid', and 'c' (content) (Section 4.4).  = If

   more = than one Uri-Query option is included in a request, = these

   = options are interpreted in the same way as when multiple = target

   = clauses are included in a message body.  If multiple values of = a

   query = parameter are included in an Uri-Query option, these = values

   MUST = be separated by a "," character without any spaces.  = Range

   values = (i.e., contiguous inclusive block) can be included for = target-

   port, = target-protocol, and 'mid' parameters by indicating two = bound

   values = separated by a "-" character..  Wildcard names (i.e., a = name

   with = the leftmost label is the "*" character) can be included = in

   = target-fqdn or target-uri parameters.  For example, = "*.example.com"

   can be = included as a value of the target-fqdn parameter in an = Uri-

   Query = option.

 

Better?

 

Cheers,

Med

 

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 21 avril 2020 16:25
=C0 : BOUCADAIR Mohamed = TGI/OLN; dots@ietf.org
Objet : RE: [Dots] multiple values = in the filter RE: DOTS telemetry Issues picked up in Interop = Testing

 

For me, - (minus) is for a range and , (comma) = for distinct elements.  Spaces not allowed.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 21 April 2020 = 15:20
To: Jon Shallow; dots@ietf.org
Subject: [Dots] = multiple values in the filter RE: DOTS telemetry Issues picked up in = Interop Testing

 

Re-, =

 

If we want to allow for multiple values to be = included, all what we need is to agree on the separator to be used for = ranges and for distinct elements. We can get rid of = [].

 

Cheers,

Med

 

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

 

 

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

 

Hi = all,

 

A further thought on the = use of Uri-Queries to clarify the AND/OR usage.

 

If you only allow one = query per query type and put the match list in an array, then this will = be an OR of the array list (the same as we do for the target* = definitions right now.  E.G. :-

 

Uri-Query: = target_prefix=3D[1.2.3.4/32,4.3.2.1/32]

Gives either 1.2.3.4 or = 4.3.2.1 as a valid match.

 

And =

Uri-Query: = target-prefix=3D[1.2.3.4/32,4.3.2.1/32]

Uri-Query: = lower-port=3D[80,443]

Gives (either 1.2.3.4 or 4.3.2.1) and (either = port 80 or 443)

 

[] should not include = spaces and comma used as a separator.

 

[Med] The issue I have with this is that we will = need to handle cases where both lower-port and upper-port are present. = Not sure what would be the benefit of allowing multiple key values, = compact uris? If that’s a concern, we may consider shortened names = in the query (e.g., s/target-prefix/tp, s/lower-port/lp, = ..).

 

Jon> fair point about lower and upper = ports..  Uri-Query: target-port[80-85,443] works for me and covers = both ranges and individual ports.

 

Jon> As this would be = options on a GET request that has no body data, I don’t think that = I am too worried about using shortened names at this = point.

 

 

------=_NextPart_000_00B5_01D61891.5CE9F790-- From nobody Thu Apr 23 02:48:56 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 4263E3A17F3 for ; Thu, 23 Apr 2020 02:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 E05C0LvGqRQN for ; Thu, 23 Apr 2020 02:48:52 -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 37C473A17F2 for ; Thu, 23 Apr 2020 02:48:51 -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 1jRYTL-0005Yn-Ex for ietf-supjps-dots@ietf.org; Thu, 23 Apr 2020 10:48:43 +0100 From: "Jon Shallow" To: Date: Thu, 23 Apr 2020 10:48:51 +0100 Message-ID: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020B_01D6195C.C6796B20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdYZVGSfUZa45G/WRP2eUjBc2dtf7w== Content-Language: en-gb Archived-At: Subject: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 09:48:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_020B_01D6195C.C6796B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, When passing telemetry attack information back and forth, there are some ways that we need to consider on data reduction, thus reducing the likelihood of having to do Block transfers. My understanding is that there is a one-to-one relationship between "attack-id" and "attack-name". My first suggestion is that the client is able to upload to a server, and the server can download on request, a vendor's mapping of "attack-id" to "attack-name" for the specific vendor "id". Then, whenever there is telemetry information "id" + "attack-id" need to be provided, but much space can be saved by not having to also include "attack-name". Second suggestion is that "attack-id" is an integer instead of a string to again save on space in the telemetry data. Regards Jon ------=_NextPart_000_020B_01D6195C.C6796B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

When passing telemetry attack information back and = forth, there are some ways that we need to consider on data reduction, = thus reducing the likelihood of having to do Block = transfers.

 

My understanding is that there is a one-to-one = relationship between “attack-id” and = “attack-name”.

 

My first = suggestion is that the client is able to upload to a server, and the = server can download on request, a vendor’s mapping of = “attack-id” to “attack-name” for the specific = vendor “id”.  Then, whenever there is telemetry = information ”id” + “attack-id” need to be = provided, but much space can be saved by not having to also include = “attack-name”.

 

Second = suggestion is that “attack-id” is an integer instead of a = string to again save on space in the telemetry data.

 

Regards

 

Jon

------=_NextPart_000_020B_01D6195C.C6796B20-- From nobody Tue Apr 28 01:29:31 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 BB02A3A0F6F for ; Tue, 28 Apr 2020 01:29:29 -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 84HMTVXgJbSh for ; Tue, 28 Apr 2020 01:29:28 -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 04E933A0F68 for ; Tue, 28 Apr 2020 01:29:25 -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 1jTLcF-0004qN-Q0 for ietf-supjps-dots@ietf.org; Tue, 28 Apr 2020 09:29:20 +0100 From: "Jon Shallow" To: References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> In-Reply-To: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> Date: Tue, 28 Apr 2020 09:29:27 +0100 Message-ID: <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01D61D3F.83638190" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestKhfzPjg Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:29:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A4_01D61D3F.83638190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, Any thoughts on this data reduction? While it is possible for a Vendor to come up with their own augmented YANG to cover their vendor specifics, it gets problematic when 2 or more Vendor specifics need to be understood by a client or a server. Having a "/vendor-mapping" operation path means that vendor mapping of "attack-id" and "attack-name" can easily be exchanged. If "attack-id" is an integer instead of a string, then "attack-id" could become a Vendor specific set of enums (they do not need to start from 1) based on "id". Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, When passing telemetry attack information back and forth, there are some ways that we need to consider on data reduction, thus reducing the likelihood of having to do Block transfers. My understanding is that there is a one-to-one relationship between "attack-id" and "attack-name". My first suggestion is that the client is able to upload to a server, and the server can download on request, a vendor's mapping of "attack-id" to "attack-name" for the specific vendor "id". Then, whenever there is telemetry information "id" + "attack-id" need to be provided, but much space can be saved by not having to also include "attack-name". Second suggestion is that "attack-id" is an integer instead of a string to again save on space in the telemetry data. Regards Jon ------=_NextPart_000_00A4_01D61D3F.83638190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Any thoughts on this = data reduction?

 

While it is possible for = a Vendor to come up with their own augmented YANG to cover their vendor = specifics, it gets problematic when 2 or more Vendor specifics need to = be understood by a client or a server.

 

Having a = “/vendor-mapping” operation path means that vendor mapping = of “attack-id” and “attack-name” can easily be = exchanged.

 

If = “attack-id” is an integer instead of a string, then = “attack-id” could become a Vendor specific set of enums = (they do not need to start from 1) based on = “id”.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Jon Shallow
Sent: 23 April 2020 10:49
To: = dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific = data reduction

 

Hi = All,

 

When passing telemetry attack information back and = forth, there are some ways that we need to consider on data reduction, = thus reducing the likelihood of having to do Block = transfers.

 

My understanding is that there is a one-to-one = relationship between “attack-id” and = “attack-name”.

 

My first = suggestion is that the client is able to upload to a server, and the = server can download on request, a vendor’s mapping of = “attack-id” to “attack-name” for the specific = vendor “id”.  Then, whenever there is telemetry = information ”id” + “attack-id” need to be = provided, but much space can be saved by not having to also include = “attack-name”.

 

Second = suggestion is that “attack-id” is an integer instead of a = string to again save on space in the telemetry data.

 

Regards

 

Jon

------=_NextPart_000_00A4_01D61D3F.83638190-- From nobody Tue Apr 28 04:00:30 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 761BD3A134B for ; Tue, 28 Apr 2020 04:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhv__KDgfNWz for ; Tue, 28 Apr 2020 04:00:26 -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 B438B3A1349 for ; Tue, 28 Apr 2020 04:00:25 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 49BJZw0yKrz10Cw; Tue, 28 Apr 2020 13:00:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588071624; bh=p5znIcmZmTAHCMFdHbMhk2BeUJNYdrPsRrZtGPur4P4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=nX0EzR7ko8SRFKhe+AJnztrQNTS7omdPOIH4R4k7AsjAJ1O1ps179aCfP3WrhGEvZ yf/gyMPWkN0yIPlZ5CCzdpxkEGQPjxtu5k+g3QggvlyEoTIgRrOPwVUXWtvUl3TzRX 0uGBvRdgDdcVcr4EBegr2dlgpGvIcg8vTKFeI6TdKFDIAEYx24Rz/BVRc1fD8uDS8z OtkkHL2iYsQJKA/70CN69gesIHxFJzPFL4XT73g95VuqIKV5aFJVa2v43GwOnpsOEy B5LCd6BwyOLqmTicy+cqtudnZvYI+60U22Bvo8hVC139Axy/NP1oiyxjJU5eaHbudy EoIDeYb0igdkA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 49BJZv756nzDq86; Tue, 28 Apr 2020 13:00:23 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction Thread-Index: AQHtT51gUZa45G/WRP2eUjBc2dtf76hfzPjggAAIUDA= Date: Tue, 28 Apr 2020 11:00:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> In-Reply-To: <00a301d61d37$219f1990$64dd4cb0$@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_787AE7BB302AE849A7480A190F8B9330314A0CEDOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 11:00:28 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314A0CEDOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Apologies for the delay to follow on this one. attack-name is more about a description than a name. This field may also be= used to map attack details from distinct vendors because there is no a glo= bal registry (and we don't want to create one). Having the ability to retrieve a list prior to an attack is interesting to = consider but the (optional) attribute may still be needed to be included fo= r new attack types. Note that the name attribute is also used by a DOTS client to send telemetr= y to a DOTS server. Attack-id is defined as a string because we inspired from existing event no= tification formats. Some of these formats allow for an even ID to be intege= r or string. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, Any thoughts on this data reduction? While it is possible for a Vendor to come up with their own augmented YANG = to cover their vendor specifics, it gets problematic when 2 or more Vendor = specifics need to be understood by a client or a server. Having a "/vendor-mapping" operation path means that vendor mapping of "att= ack-id" and "attack-name" can easily be exchanged. If "attack-id" is an integer instead of a string, then "attack-id" could be= come a Vendor specific set of enums (they do not need to start from 1) base= d on "id". Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, When passing telemetry attack information back and forth, there are some wa= ys that we need to consider on data reduction, thus reducing the likelihood= of having to do Block transfers. My understanding is that there is a one-to-one relationship between "attack= -id" and "attack-name". My first suggestion is that the client is able to upload to a server, and t= he server can download on request, a vendor's mapping of "attack-id" to "at= tack-name" for the specific vendor "id". Then, whenever there is telemetry= information "id" + "attack-id" need to be provided, but much space can be = saved by not having to also include "attack-name". Second suggestion is that "attack-id" is an integer instead of a string to = again save on space in the telemetry data. Regards Jon --_000_787AE7BB302AE849A7480A190F8B9330314A0CEDOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Apologies for the delay to follow on this one.

 

attack-name is more about a description than a name. This fie= ld may also be used to map attack details from distinct vendors because the= re is no a global registry (and we don’t want to create one).

 

Having the ability to retrieve a list prior to an attack is i= nteresting to consider but the (optional) attribute may still be needed to = be included for new attack types.

 

Note that the name attribute is also used by a DOTS client to= send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired from exi= sting event notification formats. Some of these formats allow for an even I= D to be integer or string.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mardi 28 avril 2020 10:29
=C0 : dots@ietf.org
Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi All,=

&n= bsp;

Any tho= ughts on this data reduction?

&n= bsp;

While i= t is possible for a Vendor to come up with their own augmented YANG to cove= r their vendor specifics, it gets problematic when 2 or more Vendor specifi= cs need to be understood by a client or a server.

&n= bsp;

Having = a “/vendor-mapping” operation path means that vendor mapping of= “attack-id” and “attack-name” can easily be exchan= ged.

&n= bsp;

If R= 20;attack-id” is an integer instead of a string, then “attack-i= d” could become a Vendor specific set of enums (they do not need to s= tart from 1) based on “id”.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ie= tf.org] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific data reduction=

 

Hi All,

 

When passing telemetry attack i= nformation back and forth, there are some ways that we need to consider on = data reduction, thus reducing the likelihood of having to do Block transfer= s.

 

My understanding is that there = is a one-to-one relationship between “attack-id” and “att= ack-name”.

 

My first suggestion is that the= client is able to upload to a server, and the server can download on reque= st, a vendor’s mapping of “attack-id” to “attack-na= me” for the specific vendor “id”.  Then, whenever th= ere is telemetry information ”id” + “attack-id” need to be prov= ided, but much space can be saved by not having to also include “atta= ck-name”.

 

Second suggestion is that ̶= 0;attack-id” is an integer instead of a string to again save on space= in the telemetry data.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B9330314A0CEDOPEXCAUBMA2corp_-- From nobody Tue Apr 28 06:57:56 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 B7A003A157C for ; Tue, 28 Apr 2020 06:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6OF5W_Rh89Q for ; Tue, 28 Apr 2020 06:57:54 -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 F09A73A15FE for ; Tue, 28 Apr 2020 06:57:42 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 49BNWT4tM0z4wZ5 for ; Tue, 28 Apr 2020 15:57:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588082261; bh=iq5oueYSlw0nR1AQ45qUi8QnRAIWUOxz32kCOMqNG7k=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Stq55WIMK199kDKfjWwBKZOokjcXjo3XG3Coe/kblOR13RxPXtRvcVufcUj3kKs9Z rh6CfQwYPVXhqg2yba9m1ntiZcHeHAYOGaamrG/WUr2uiuC5NqoD8ZLffN+I8YT6/+ oBPWjOKdlD7mc69HtnoqbBxqN1Oc41NyhynulYJA2KGR0lQNRkc+x9GCL5ZRTDlAb7 Gq1OH3jU6kW1yWIqUdGUF8ILeN6GCvjqFaF5U8XxJG+2V7rsYi+EqKl0ZY91Ur+u/T 07A4q+1rCpHvd8wPkkkbr3BpVE1Ees24N5GazKVIJjOk7qdffFLxY0U0B29zlZfLa5 ORDZDmCFQ/WZw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 49BNWT43RnzDq7k for ; Tue, 28 Apr 2020 15:57:41 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: draft-ietf-dots-telemetry: severity levels Thread-Index: AdYdZPr5wJ0VQQ6TQHCUMixwn9oMcw== Date: Tue, 28 Apr 2020 13:57:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314A0F51@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_787AE7BB302AE849A7480A190F8B9330314A0F51OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-telemetry: severity levels 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, 28 Apr 2020 13:57:56 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314A0F51OPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, attack-severity values as currently defined in the draft are mapped from th= ose of the Severity level indicator in SYSLOG (RFC5424): Emergency, Alert, = and Critical. We are planning to change those values and use the ones defined in this reg= istry: http://www.iana.org/assignments/iodef2/iodef2.xhtml#businessimpact-s= everity. Any objection? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330314A0F51OPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi all,

=  

attack-severity values as currently defined in the draft are mapped fr=
om those of the Severity level indicator in SYSLOG (RFC5424): Emergency, Al=
ert, and Critical.

=  

= We are planning to change those values and use the ones defined in this reg= istry: http://www.iana.org/assignments/iodef2/iodef2.xhtml#businessimpact-severity= .   

=  

= Any objection?

=  

= Cheers,

= Med

--_000_787AE7BB302AE849A7480A190F8B9330314A0F51OPEXCAUBMA2corp_-- From nobody Tue Apr 28 07:09:05 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 492F23A15A6 for ; Tue, 28 Apr 2020 07:09:04 -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 Af7C-cFELfDh for ; Tue, 28 Apr 2020 07:09:01 -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 05F8B3A15A4 for ; Tue, 28 Apr 2020 07:09:00 -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 1jTQuw-00054v-Cf; Tue, 28 Apr 2020 15:08:58 +0100 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B9330314A0F51@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314A0F51@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 28 Apr 2020 15:09:06 +0100 Message-ID: <015601d61d66$94132280$bc396780$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0157_01D61D6E.F5D91120" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQDhGDIIALPUvLXqFzp+pNgG5AJRwqp4nIlQ Archived-At: Subject: Re: [Dots] draft-ietf-dots-telemetry: severity levels 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, 28 Apr 2020 14:09:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0157_01D61D6E.F5D91120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Med, This works for me. Regards Jon From: Dots [mailto:-dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 14:58 To: dots@ietf.org Subject: [Dots] draft-ietf-dots-telemetry: severity levels Hi all, attack-severity values as currently defined in the draft are mapped from those of the Severity level indicator in SYSLOG (RFC5424): Emergency, Alert, and Critical. We are planning to change those values and use the ones defined in this registry: http://www.iana.org/assignments/iodef2/iodef2.xhtml#businessimpact-severity. Any objection? Cheers, Med ------=_NextPart_000_0157_01D61D6E.F5D91120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

This works for = me.

 

Regards

 

Jon

 

From:= Dots = [mailto:-dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 28 April 2020 = 14:58
To: dots@ietf.org
Subject: [Dots] = draft-ietf-dots-telemetry: severity = levels

 

Hi all, =

 

attack-severity values as currently defined in the draft =
are mapped from those of the Severity level indicator in SYSLOG =
(RFC5424): Emergency, Alert, and Critical.

 

We are planning to = change those values and use the ones defined in this registry: http://www.iana.org/assignments/iodef2/iodef2.xhtml#businessi= mpact-severity.   

 

Any = objection?

 

Cheers,

Med

------=_NextPart_000_0157_01D61D6E.F5D91120-- From nobody Tue Apr 28 08:16: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 BE6833A172F for ; Tue, 28 Apr 2020 08:15:59 -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 9CNPsLNFHfLy for ; Tue, 28 Apr 2020 08:15:57 -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 74E2A3A1729 for ; Tue, 28 Apr 2020 08:15:43 -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 1jTRxS-00056v-21; Tue, 28 Apr 2020 16:15:38 +0100 From: "Jon Shallow" To: , References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 28 Apr 2020 16:15:45 +0100 Message-ID: <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0173_01D61D78.45D16480" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWWoP1QcgA== Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 15:16:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0173_01D61D78.45D16480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 To give an example for =93attack-id=94 and =93attack-name=94 the DDOS = Mitigator that I work with has several components that identify the same attack =20 Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: =93TCP Attack - Syn Flood" =20 And in the code I was using the index for =93attack-id=94 and the Descriptive-Name for the =93attack-name=94 for the recent telemetry = Interop with Kaname. =20 With a multi-vector attack, the descriptive name information was a substantive part of the telemetry information being passed back to the client. =20 Similarly, if the DDoS Mitigator was to act as a client to an upstream = DOTS server (which in my case it can), then again there is a lot of = information being relayed that could be reduced with a mapping between=94 = attack-id=94 and =93attack-name=94 for a specific vendor =93id=94 being uploaded ahead of = time =96 and can be refreshed if new attacks are discovered and mitigated. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon, =20 Apologies for the delay to follow on this one.=20 =20 attack-name is more about a description than a name. This field may also = be used to map attack details from distinct vendors because there is no a global registry (and we don=92t want to create one).=20 =20 Having the ability to retrieve a list prior to an attack is interesting = to consider but the (optional) attribute may still be needed to be included = for new attack types.=20 =20 Note that the name attribute is also used by a DOTS client to send = telemetry to a DOTS server.=20 =20 Attack-id is defined as a string because we inspired from existing event notification formats. Some of these formats allow for an even ID to be integer or string.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 Any thoughts on this data reduction? =20 While it is possible for a Vendor to come up with their own augmented = YANG to cover their vendor specifics, it gets problematic when 2 or more = Vendor specifics need to be understood by a client or a server. =20 Having a =93/vendor-mapping=94 operation path means that vendor mapping = of =93attack-id=94 and =93attack-name=94 can easily be exchanged. =20 If =93attack-id=94 is an integer instead of a string, then = =93attack-id=94 could become a Vendor specific set of enums (they do not need to start from 1) based on =93id=94. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 When passing telemetry attack information back and forth, there are some ways that we need to consider on data reduction, thus reducing the likelihood of having to do Block transfers. =20 My understanding is that there is a one-to-one relationship between =93attack-id=94 and =93attack-name=94. =20 My first suggestion is that the client is able to upload to a server, = and the server can download on request, a vendor=92s mapping of = =93attack-id=94 to =93attack-name=94 for the specific vendor =93id=94. Then, whenever = there is telemetry information =94id=94 + =93attack-id=94 need to be provided, = but much space can be saved by not having to also include =93attack-name=94. =20 Second suggestion is that =93attack-id=94 is an integer instead of a = string to again save on space in the telemetry data. =20 Regards =20 Jon ------=_NextPart_000_0173_01D61D78.45D16480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

To give an example for = “attack-id” and “attack-name” the DDOS Mitigator = that I work with has several components that identify the same = attack

 

Index: = 3016

Short-Name: = tcpattack_synflood

Descriptive-Name: “TCP Attack - Syn = Flood"

 

And in the code I was = using the index for “attack-id” and the Descriptive-Name for = the “attack-name” for the recent telemetry Interop with = Kaname.

 

With a multi-vector = attack, the descriptive name information was a substantive part of the = telemetry information being passed back to the = client.

 

Similarly, if the DDoS = Mitigator was to act as a client to an upstream DOTS server (which in my = case it can), then again there is a lot of information being relayed = that could be reduced with a mapping between” attack-id” and = “attack-name” for a specific vendor “id” being = uploaded ahead of time – and can be refreshed if new attacks are = discovered and mitigated.

 

Regards

 

Jon

 

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

 

Hi = Jon,

 

Apologies for the delay to follow on this one. =

 

attack-name is more about a description than a name. = This field may also be used to map attack details from distinct vendors = because there is no a global registry (and we don’t want to create = one).

 

Having the ability to retrieve a list prior to an = attack is interesting to consider but the (optional) attribute may still = be needed to be included for new attack types.

 

Note that the name attribute is also used by a DOTS = client to send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired = from existing event notification formats. Some of these formats allow = for an even ID to be integer or string.

 

Cheers,

Med

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : mardi 28 avril 2020 = 10:29
=C0 : dots@ietf.org
Objet : Re: = [Dots] Telemetry draft: Vendor Specific data = reduction

 

Hi All,

 

Any thoughts on this = data reduction?

 

While it is possible for = a Vendor to come up with their own augmented YANG to cover their vendor = specifics, it gets problematic when 2 or more Vendor specifics need to = be understood by a client or a server.

 

Having a = “/vendor-mapping” operation path means that vendor mapping = of “attack-id” and “attack-name” can easily be = exchanged.

 

If = “attack-id” is an integer instead of a string, then = “attack-id” could become a Vendor specific set of enums = (they do not need to start from 1) based on = “id”.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: 23 April 2020 10:49
To: = dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific = data reduction

 

Hi = All,

 

When passing telemetry attack information back and = forth, there are some ways that we need to consider on data reduction, = thus reducing the likelihood of having to do Block = transfers.

 

My understanding is that there is a one-to-one = relationship between “attack-id” and = “attack-name”.

 

My first = suggestion is that the client is able to upload to a server, and the = server can download on request, a vendor’s mapping of = “attack-id” to “attack-name” for the specific = vendor “id”.  Then, whenever there is telemetry = information ”id” + “attack-id” need to be = provided, but much space can be saved by not having to also include = “attack-name”.

 

Second = suggestion is that “attack-id” is an integer instead of a = string to again save on space in the telemetry data.

 

Regards

 

Jon

------=_NextPart_000_0173_01D61D78.45D16480-- From nobody Tue Apr 28 08:56: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 B01533A03EF for ; Tue, 28 Apr 2020 08:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWhaYPAMyqkw for ; Tue, 28 Apr 2020 08:56:46 -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 3AB753A03EE for ; Tue, 28 Apr 2020 08:56:46 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 49BR8q5CCcz1ygN; Tue, 28 Apr 2020 17:56:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588089403; bh=4+iCWriHFP8TGcJemrx8V76w31L7+JRY0vFyP75ErVI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=V3GiOC8Ji+VoFH8SSWpkjFPPSwwYMgX8Uj2qUhmK3mSxj4XcI6F7LDs+hDiYiAKzg yxZ/KrhEizgW3gXwFOjGx4Xx9peIrU9sSxuDmYqZGACkyUkM8g+UIOL04gS6PVgOF3 6yS52ucFSRponTuOwOLI9iHyoFzT8YOiDBKYmveV+w7iEQxAQXT42JxGk4MQh9dsty 2+1B0Wm57IXa2nPUClRDWMFqbQ2p3G0cqOUSjjFh2XQ2O3ko4KainA0efkoHxtj5Lj 24kCPq5CKgiN4I6T+qAGB84mpVW3ePzE3zZzUxnhrxGMVJNQO77X1AsvKx2aNqfe9I ZqurNJFTBHdPg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 49BR8q4FDGz8sY1; Tue, 28 Apr 2020 17:56:43 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWWoP1QcgIAAFv1Q Date: Tue, 28 Apr 2020 15:56:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> In-Reply-To: <017201d61d6f$e40b75e0$ac2261a0$@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_787AE7BB302AE849A7480A190F8B9330314A10FFOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 15:56:49 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314A10FFOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, If attack-name is completely removed for the attack-details, this means the= remote peer can't make use of the information till the list is refreshed. Isn't better to maintain the attribute as in the current design but an agen= t uses this attribute only for new attacks? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, To give an example for "attack-id" and "attack-name" the DDOS Mitigator tha= t I work with has several components that identify the same attack Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: "TCP Attack - Syn Flood" And in the code I was using the index for "attack-id" and the Descriptive-N= ame for the "attack-name" for the recent telemetry Interop with Kaname. With a multi-vector attack, the descriptive name information was a substant= ive part of the telemetry information being passed back to the client. Similarly, if the DDoS Mitigator was to act as a client to an upstream DOTS= server (which in my case it can), then again there is a lot of information= being relayed that could be reduced with a mapping between" attack-id" and= "attack-name" for a specific vendor "id" being uploaded ahead of time - an= d can be refreshed if new attacks are discovered and mitigated. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi Jon, Apologies for the delay to follow on this one. attack-name is more about a description than a name. This field may also be= used to map attack details from distinct vendors because there is no a glo= bal registry (and we don't want to create one). Having the ability to retrieve a list prior to an attack is interesting to = consider but the (optional) attribute may still be needed to be included fo= r new attack types. Note that the name attribute is also used by a DOTS client to send telemetr= y to a DOTS server. Attack-id is defined as a string because we inspired from existing event no= tification formats. Some of these formats allow for an even ID to be intege= r or string. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, Any thoughts on this data reduction? While it is possible for a Vendor to come up with their own augmented YANG = to cover their vendor specifics, it gets problematic when 2 or more Vendor = specifics need to be understood by a client or a server. Having a "/vendor-mapping" operation path means that vendor mapping of "att= ack-id" and "attack-name" can easily be exchanged. If "attack-id" is an integer instead of a string, then "attack-id" could be= come a Vendor specific set of enums (they do not need to start from 1) base= d on "id". Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, When passing telemetry attack information back and forth, there are some wa= ys that we need to consider on data reduction, thus reducing the likelihood= of having to do Block transfers. My understanding is that there is a one-to-one relationship between "attack= -id" and "attack-name". My first suggestion is that the client is able to upload to a server, and t= he server can download on request, a vendor's mapping of "attack-id" to "at= tack-name" for the specific vendor "id". Then, whenever there is telemetry= information "id" + "attack-id" need to be provided, but much space can be = saved by not having to also include "attack-name". Second suggestion is that "attack-id" is an integer instead of a string to = again save on space in the telemetry data. Regards Jon --_000_787AE7BB302AE849A7480A190F8B9330314A10FFOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

If attack-name is completely removed for the attack-details, = this means the remote peer can’t make use of the information till the= list is refreshed.

 

Isn’t better to maintain the attribute as in the curren= t design but an agent uses this attribute only for new attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed TGI/OLN;= dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

To give= an example for “attack-id” and “attack-name” the D= DOS Mitigator that I work with has several components that identify the sam= e attack

&n= bsp;

Index: = 3016

Short-N= ame: tcpattack_synflood

Descrip= tive-Name: “TCP Attack - Syn Flood"

&n= bsp;

And in = the code I was using the index for “attack-id” and the Descript= ive-Name for the “attack-name” for the recent telemetry Interop= with Kaname.

&n= bsp;

With a = multi-vector attack, the descriptive name information was a substantive par= t of the telemetry information being passed back to the client.<= /span>

&n= bsp;

Similar= ly, if the DDoS Mitigator was to act as a client to an upstream DOTS server= (which in my case it can), then again there is a lot of information being = relayed that could be reduced with a mapping between” attack-id” and “attack-name” for a specif= ic vendor “id” being uploaded ahead of time – and can be = refreshed if new attacks are discovered and mitigated.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 12:00
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Hi Jon,

 

Apologies for the delay to follow on this one.

 

attack-name is more about a description than a name. This fie= ld may also be used to map attack details from distinct vendors because the= re is no a global registry (and we don’t want to create one).

 

Having the ability to retrieve a list prior to an attack is i= nteresting to consider but the (optional) attribute may still be needed to = be included for new attack types.

 

Note that the name attribute is also used by a DOTS client to= send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired from exi= sting event notification formats. Some of these formats allow for an even I= D to be integer or string.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mardi 28 avril 2020 10:29
=C0 : dots@ietf.org
Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi All,=

&n= bsp;

Any tho= ughts on this data reduction?

&n= bsp;

While i= t is possible for a Vendor to come up with their own augmented YANG to cove= r their vendor specifics, it gets problematic when 2 or more Vendor specifi= cs need to be understood by a client or a server.

&n= bsp;

Having = a “/vendor-mapping” operation path means that vendor mapping of= “attack-id” and “attack-name” can easily be exchan= ged.

&n= bsp;

If R= 20;attack-id” is an integer instead of a string, then “attack-i= d” could become a Vendor specific set of enums (they do not need to s= tart from 1) based on “id”.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific data reduction=

 

Hi All,

 

When passing telemetry attack i= nformation back and forth, there are some ways that we need to consider on = data reduction, thus reducing the likelihood of having to do Block transfer= s.

 

My understanding is that there = is a one-to-one relationship between “attack-id” and “att= ack-name”.

 

My first suggestion is that the= client is able to upload to a server, and the server can download on reque= st, a vendor’s mapping of “attack-id” to “attack-na= me” for the specific vendor “id”.  Then, whenever th= ere is telemetry information ”id” + “attack-id” need to be prov= ided, but much space can be saved by not having to also include “atta= ck-name”.

 

Second suggestion is that ̶= 0;attack-id” is an integer instead of a string to again save on space= in the telemetry data.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B9330314A10FFOPEXCAUBMA2corp_-- From nobody Tue Apr 28 12:24:05 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 2682E3A0A4B for ; Tue, 28 Apr 2020 12:24:03 -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 uI2jtPVTKr12 for ; Tue, 28 Apr 2020 12:24:00 -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 1429C3A0A01 for ; Tue, 28 Apr 2020 12:23: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 1jTVpl-0005Fj-KN; Tue, 28 Apr 2020 20:23:57 +0100 From: "Jon Shallow" To: , References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 28 Apr 2020 20:24:05 +0100 Message-ID: <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D4_01D61D9A.F68FB2F0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLqB2eBIA= Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 19:24:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D4_01D61D9A.F68FB2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 I was not thinking of dropping attack-name. I was more thinking of uploading / downloading as appropriate the entire list of id->attack-id<->attack-name. The attack-id<->attack-name list will = evolve over time so there will need to be a mechanism of doing updates, or signalling that there are new attack-id in use. =20 However, the first time that an attack-id is used, the attack-name can = also be included. Two immediate issues that come to mind are=20 =93What happens if the telemetry information packet that contains the attack-name gets lost in transit=94 =93If a major attack kicks off with many vectors, all of the attack-ids = for the first time, there will be a lot of traffic=94 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 16:57 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Re-,=20 =20 If attack-name is completely removed for the attack-details, this means = the remote peer can=92t make use of the information till the list is = refreshed.=20 =20 Isn=92t better to maintain the attribute as in the current design but an = agent uses this attribute only for new attacks?=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 To give an example for =93attack-id=94 and =93attack-name=94 the DDOS = Mitigator that I work with has several components that identify the same attack =20 Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: =93TCP Attack - Syn Flood" =20 And in the code I was using the index for =93attack-id=94 and the Descriptive-Name for the =93attack-name=94 for the recent telemetry = Interop with Kaname. =20 With a multi-vector attack, the descriptive name information was a substantive part of the telemetry information being passed back to the client. =20 Similarly, if the DDoS Mitigator was to act as a client to an upstream = DOTS server (which in my case it can), then again there is a lot of = information being relayed that could be reduced with a mapping between=94 = attack-id=94 and =93attack-name=94 for a specific vendor =93id=94 being uploaded ahead of = time =96 and can be refreshed if new attacks are discovered and mitigated. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon, =20 Apologies for the delay to follow on this one.=20 =20 attack-name is more about a description than a name. This field may also = be used to map attack details from distinct vendors because there is no a global registry (and we don=92t want to create one).=20 =20 Having the ability to retrieve a list prior to an attack is interesting = to consider but the (optional) attribute may still be needed to be included = for new attack types.=20 =20 Note that the name attribute is also used by a DOTS client to send = telemetry to a DOTS server.=20 =20 Attack-id is defined as a string because we inspired from existing event notification formats. Some of these formats allow for an even ID to be integer or string.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 Any thoughts on this data reduction? =20 While it is possible for a Vendor to come up with their own augmented = YANG to cover their vendor specifics, it gets problematic when 2 or more = Vendor specifics need to be understood by a client or a server. =20 Having a =93/vendor-mapping=94 operation path means that vendor mapping = of =93attack-id=94 and =93attack-name=94 can easily be exchanged. =20 If =93attack-id=94 is an integer instead of a string, then = =93attack-id=94 could become a Vendor specific set of enums (they do not need to start from 1) based on =93id=94. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 When passing telemetry attack information back and forth, there are some ways that we need to consider on data reduction, thus reducing the likelihood of having to do Block transfers. =20 My understanding is that there is a one-to-one relationship between =93attack-id=94 and =93attack-name=94. =20 My first suggestion is that the client is able to upload to a server, = and the server can download on request, a vendor=92s mapping of = =93attack-id=94 to =93attack-name=94 for the specific vendor =93id=94. Then, whenever = there is telemetry information =94id=94 + =93attack-id=94 need to be provided, = but much space can be saved by not having to also include =93attack-name=94. =20 Second suggestion is that =93attack-id=94 is an integer instead of a = string to again save on space in the telemetry data. =20 Regards =20 Jon ------=_NextPart_000_01D4_01D61D9A.F68FB2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I was not thinking of = dropping attack-name.=A0 I was more thinking of uploading / downloading = as appropriate the entire list of = id->attack-id<->attack-name.=A0 The = attack-id<->attack-name list will evolve over time so there will = need to be a mechanism of doing updates, or signalling that there are = new attack-id in use.

 

However, the first time = that an attack-id is used, the attack-name can also be included.=A0 Two = immediate issues that come to mind are

“What happens if = the telemetry information packet that contains the attack-name gets lost = in transit”

“If a major attack kicks off with many = vectors, all of the attack-ids for the first time, there will be a lot = of traffic”

 

Regards

 

Jon

 

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

 

Re-, =

 

If attack-name is completely removed for the = attack-details, this means the remote peer can’t make use of the = information till the list is refreshed.

 

Isn’t better to maintain the attribute as in = the current design but an agent uses this attribute only for new = attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed = TGI/OLN; = dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor = Specific data reduction

 

Hi = Med,

 

To give an example for = “attack-id” and “attack-name” the DDOS Mitigator = that I work with has several components that identify the same = attack

 

Index: = 3016

Short-Name: = tcpattack_synflood

Descriptive-Name: “TCP Attack - Syn = Flood"

 

And in the code I was = using the index for “attack-id” and the Descriptive-Name for = the “attack-name” for the recent telemetry Interop with = Kaname.

 

With a multi-vector = attack, the descriptive name information was a substantive part of the = telemetry information being passed back to the = client.

 

Similarly, if the DDoS = Mitigator was to act as a client to an upstream DOTS server (which in my = case it can), then again there is a lot of information being relayed = that could be reduced with a mapping between” attack-id” and = “attack-name” for a specific vendor “id” being = uploaded ahead of time – and can be refreshed if new attacks are = discovered and mitigated.

 

Regards

 

Jon

 

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

 

Hi = Jon,

 

Apologies for the delay to follow on this one. =

 

attack-name is more about a description than a name. = This field may also be used to map attack details from distinct vendors = because there is no a global registry (and we don’t want to create = one).

 

Having the ability to retrieve a list prior to an = attack is interesting to consider but the (optional) attribute may still = be needed to be included for new attack types.

 

Note that the name attribute is also used by a DOTS = client to send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired = from existing event notification formats. Some of these formats allow = for an even ID to be integer or string.

 

Cheers,

Med

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : mardi 28 avril 2020 = 10:29
=C0 : dots@ietf.org
Objet : Re: = [Dots] Telemetry draft: Vendor Specific data = reduction

 

Hi All,

 

Any thoughts on this = data reduction?

 

While it is possible for = a Vendor to come up with their own augmented YANG to cover their vendor = specifics, it gets problematic when 2 or more Vendor specifics need to = be understood by a client or a server.

 

Having a = “/vendor-mapping” operation path means that vendor mapping = of “attack-id” and “attack-name” can easily be = exchanged.

 

If = “attack-id” is an integer instead of a string, then = “attack-id” could become a Vendor specific set of enums = (they do not need to start from 1) based on = “id”.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: 23 April 2020 10:49
To: = dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific = data reduction

 

Hi = All,

 

When passing telemetry attack information back and = forth, there are some ways that we need to consider on data reduction, = thus reducing the likelihood of having to do Block = transfers.

 

My understanding is that there is a one-to-one = relationship between “attack-id” and = “attack-name”.

 

My first = suggestion is that the client is able to upload to a server, and the = server can download on request, a vendor’s mapping of = “attack-id” to “attack-name” for the specific = vendor “id”.  Then, whenever there is telemetry = information ”id” + “attack-id” need to be = provided, but much space can be saved by not having to also include = “attack-name”.

 

Second = suggestion is that “attack-id” is an integer instead of a = string to again save on space in the telemetry data.

 

Regards

 

Jon

<= /body> ------=_NextPart_000_01D4_01D61D9A.F68FB2F0-- From nobody Wed Apr 29 01:53:26 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 E46913A0898 for ; Wed, 29 Apr 2020 01:53: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9a9kmcSlxzq for ; Wed, 29 Apr 2020 01:53:21 -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 1A3763A0887 for ; Wed, 29 Apr 2020 01:53:21 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 49Bsjq5V5Zz1yq1; Wed, 29 Apr 2020 10:53:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588150399; bh=U7q/NuonUap8ubQrWnL1U5NT3w7Sq8rpey3g8y8jH0k=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=S6j99z21cO4WqZ48ECqd3Z8YehHgyymzjjRAIgn1dPVt7eqjwK507jeWi/00V93XV //MTliuGrPU9lNmfZJjiVnnRBxEbX2yOAhvmMeXRBqwF1vlvX5ff2y6t29fDSNOFgI j/KajpncTS7GYll9y+I6uoBms0713yY90ih4VNxnsgEso82VwZeoSpxsFgmty7T3Qs fyPoAsRPS6ADBenx4QxFv3dc9HDSHgbkGpcYwy7M6XoDlP7Gi8NhztSJQXgwLIgkTj xe+FupdidPF/1GPnCe9cy6LvGJ+3ca8WXp+5K/k4sgbeuMKeTx2InuckfOuSoY9Xbs y+QD9698zzWUQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 49Bsjq3Pv7zyQC; Wed, 29 Apr 2020 10:53:19 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLqB2eBICAAN7LAA== Date: Wed, 29 Apr 2020 08:53:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> In-Reply-To: <01d301d61d92$94c9c450$be5d4cf0$@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_787AE7BB302AE849A7480A190F8B9330314A1A69OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 08:53:25 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314A1A69OPEXCAUBMA2corp_ 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 : mardi 28 avril 2020 21:24 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, I was not thinking of dropping attack-name. I was more thinking of uploadi= ng / downloading as appropriate the entire list of id->attack-id<->attack-n= ame. The attack-id<->attack-name list will evolve over time so there will = need to be a mechanism of doing updates, or signalling that there are new a= ttack-id in use. [Med] I understood that. I was commenting on the implication on the module. Putting aside defining attack-id as an integer, I thought your proposal wou= ld be as follows (with removing attack-name from the attack-detail). +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id string | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] ... +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 ... I was suggesting to leave the name under attack-detail but use it only when= an attack-id/name mapping is not already shared with the peer. The structu= re would be as follows: +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id uint32 | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] ... +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id uint32 +--rw attack-name? string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 ... Please note that the examples we have in the draft do not include attack-na= me to insist that this is an optional attribute, e.g., =3D=3D "attack-detail": [ { "attack-id": "an-id", "start-time": "1957811234", "attack-severity": "emergency" } ] =3D=3D However, the first time that an attack-id is used, the attack-name can also= be included. [Med] That's better. My suggestion goes a little bit further: the name will= be used till the mapping table is updated. Two immediate issues that come to mind are "What happens if the telemetry information packet that contains the attack-= name gets lost in transit" [Med] We don't have this issue with the proposal above. "If a major attack kicks off with many vectors, all of the attack-ids for t= he first time, there will be a lot of traffic" [Med] Removing attack-name does not eliminate this risk. The discussion we = had about block2/4 or managing this at the DOTS layer applies here. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 28 April 2020 16:57 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Re-, If attack-name is completely removed for the attack-details, this means the= remote peer can't make use of the information till the list is refreshed. Isn't better to maintain the attribute as in the current design but an agen= t uses this attribute only for new attacks? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, To give an example for "attack-id" and "attack-name" the DDOS Mitigator tha= t I work with has several components that identify the same attack Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: "TCP Attack - Syn Flood" And in the code I was using the index for "attack-id" and the Descriptive-N= ame for the "attack-name" for the recent telemetry Interop with Kaname. With a multi-vector attack, the descriptive name information was a substant= ive part of the telemetry information being passed back to the client. Similarly, if the DDoS Mitigator was to act as a client to an upstream DOTS= server (which in my case it can), then again there is a lot of information= being relayed that could be reduced with a mapping between" attack-id" and= "attack-name" for a specific vendor "id" being uploaded ahead of time - an= d can be refreshed if new attacks are discovered and mitigated. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi Jon, Apologies for the delay to follow on this one. attack-name is more about a description than a name. This field may also be= used to map attack details from distinct vendors because there is no a glo= bal registry (and we don't want to create one). Having the ability to retrieve a list prior to an attack is interesting to = consider but the (optional) attribute may still be needed to be included fo= r new attack types. Note that the name attribute is also used by a DOTS client to send telemetr= y to a DOTS server. Attack-id is defined as a string because we inspired from existing event no= tification formats. Some of these formats allow for an even ID to be intege= r or string. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, Any thoughts on this data reduction? While it is possible for a Vendor to come up with their own augmented YANG = to cover their vendor specifics, it gets problematic when 2 or more Vendor = specifics need to be understood by a client or a server. Having a "/vendor-mapping" operation path means that vendor mapping of "att= ack-id" and "attack-name" can easily be exchanged. If "attack-id" is an integer instead of a string, then "attack-id" could be= come a Vendor specific set of enums (they do not need to start from 1) base= d on "id". Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, When passing telemetry attack information back and forth, there are some wa= ys that we need to consider on data reduction, thus reducing the likelihood= of having to do Block transfers. My understanding is that there is a one-to-one relationship between "attack= -id" and "attack-name". My first suggestion is that the client is able to upload to a server, and t= he server can download on request, a vendor's mapping of "attack-id" to "at= tack-name" for the specific vendor "id". Then, whenever there is telemetry= information "id" + "attack-id" need to be provided, but much space can be = saved by not having to also include "attack-name". Second suggestion is that "attack-id" is an integer instead of a string to = again save on space in the telemetry data. Regards Jon --_000_787AE7BB302AE849A7480A190F8B9330314A1A69OPEXCAUBMA2corp_ 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 : mardi 28 avril 2020 21:24
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

I was n= ot thinking of dropping attack-name.  I was more thinking of uploading= / downloading as appropriate the entire list of id->attack-id<->a= ttack-name.  The attack-id<->attack-name list will evolve over time so there will need to be a mechanism of doing updates, or signal= ling that there are new attack-id in use.

[Med] I understood that. I was commentin= g on the implication on the module.

 

Putting aside defining attack-id as an i= nteger, I thought your proposal would be as follows (with removing attack-n= ame from the attack-detail).

 

    +--= :(vendor-mapping) {dots-telemetry}?

    | = +--rw attack-detail* [attack-id]

    | =     +--rw vendor-id?     uint32=

    | =     +--rw attack-id      string=

    | =     +--rw attack-name    string

    +--= :(telemetry) {dots-telemetry}?

    &n= bsp;  +--rw pre-or-ongoing-mitigation* [cuid tmid]

    &n= bsp;     …

    &n= bsp;     +--rw attack-detail* [attack-id]

    &n= bsp;        +--rw vendor-id? &n= bsp;       uint32

    &n= bsp;        +--rw attack-id &nb= sp;        string

    &n= bsp;        +--rw attack-severity?&n= bsp;  attack-severity

    &n= bsp;        +--rw start-time? &= nbsp;      uint64

    &n= bsp;        +--rw end-time? &nb= sp;        uint64

    &n= bsp;        …

 

I was suggesting to leave the name under attac= k-detail but use it only when an attack-id/name mapping is not already shar= ed with the peer. The structure would be as follows:

 

    +--= :(vendor-mapping) {dots-telemetry}?

    | = +--rw attack-detail* [attack-id]

    | =     +--rw vendor-id?     uint32=

    | =     +--rw attack-id      uint32=

    | =     +--rw attack-name    string

    +--= :(telemetry) {dots-telemetry}?

    &n= bsp;  +--rw pre-or-ongoing-mitigation* [cuid tmid]

    &n= bsp;     …

    &n= bsp;     +--rw attack-detail* [attack-id]

    &n= bsp;        +--rw vendor-id? &n= bsp;       uint32

    &n= bsp;        +--rw attack-id &nb= sp;        uint32

    &n= bsp;        +--rw attack-name? =       string

    &n= bsp;        +--rw attack-severity?&n= bsp;  attack-severity

    &n= bsp;        +--rw start-time? &= nbsp;      uint64

    &n= bsp;        +--rw end-time? &nb= sp;        uint64

    &n= bsp;        …

 

Please note that the examples we have in the draft do not inc= lude attack-name to insist that this is an optional attribute, e.g.,

 

=3D=3D

         &nbs= p; "attack-detail": [

         &nbs= p;   {

         &nbs= p;     "attack-id": "an-id",

         &nbs= p;     "start-time": "1957811234",<= o:p>

         &nbs= p;     "attack-severity": "emergency&quo= t;

         &nbs= p;   }

         &nbs= p; ]

=3D=3D

&n= bsp;

However= , the first time that an attack-id is used, the attack-name can also be inc= luded.

[Med] That’s better. My suggestion= goes a little bit further: the name will be used till the mapping table is= updated.  

 

  = Two immediate issues that come to mind are

“= What happens if the telemetry information packet that contains the attack-n= ame gets lost in transit”

[Med] We don’t have this issue wit= h the proposal above.

 

“= If a major attack kicks off with many vectors, all of the attack-ids for th= e first time, there will be a lot of traffic”

&n= bsp;

[Med] Removing attack-name does not elim= inate this risk. The discussion we had about block2/4 or managing this at t= he DOTS layer applies here.  

 

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 16:57
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Re-,

 

If attack-name is completely removed for the attack-details, = this means the remote peer can’t make use of the information till the= list is refreshed.

 

Isn’t better to maintain the attribute as in the curren= t design but an agent uses this attribute only for new attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed TGI/OLN;= dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

To give= an example for “attack-id” and “attack-name” the D= DOS Mitigator that I work with has several components that identify the sam= e attack

&n= bsp;

Index: = 3016

Short-N= ame: tcpattack_synflood

Descrip= tive-Name: “TCP Attack - Syn Flood"

&n= bsp;

And in = the code I was using the index for “attack-id” and the Descript= ive-Name for the “attack-name” for the recent telemetry Interop= with Kaname.

&n= bsp;

With a = multi-vector attack, the descriptive name information was a substantive par= t of the telemetry information being passed back to the client.<= /span>

&n= bsp;

Similar= ly, if the DDoS Mitigator was to act as a client to an upstream DOTS server= (which in my case it can), then again there is a lot of information being = relayed that could be reduced with a mapping between” attack-id” and “attack-name” for a specif= ic vendor “id” being uploaded ahead of time – and can be = refreshed if new attacks are discovered and mitigated.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 12:00
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Hi Jon,

 

Apologies for the delay to follow on this one.

 

attack-name is more about a description than a name. This fie= ld may also be used to map attack details from distinct vendors because the= re is no a global registry (and we don’t want to create one).

 

Having the ability to retrieve a list prior to an attack is i= nteresting to consider but the (optional) attribute may still be needed to = be included for new attack types.

 

Note that the name attribute is also used by a DOTS client to= send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired from exi= sting event notification formats. Some of these formats allow for an even I= D to be integer or string.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mardi 28 avril 2020 10:29
=C0 : dots@ietf.org
Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi All,=

&n= bsp;

Any tho= ughts on this data reduction?

&n= bsp;

While i= t is possible for a Vendor to come up with their own augmented YANG to cove= r their vendor specifics, it gets problematic when 2 or more Vendor specifi= cs need to be understood by a client or a server.

&n= bsp;

Having = a “/vendor-mapping” operation path means that vendor mapping of= “attack-id” and “attack-name” can easily be exchan= ged.

&n= bsp;

If R= 20;attack-id” is an integer instead of a string, then “attack-i= d” could become a Vendor specific set of enums (they do not need to s= tart from 1) based on “id”.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific data reduction=

 

Hi All,

 

When passing telemetry attack i= nformation back and forth, there are some ways that we need to consider on = data reduction, thus reducing the likelihood of having to do Block transfer= s.

 

My understanding is that there = is a one-to-one relationship between “attack-id” and “att= ack-name”.

 

My first suggestion is that the= client is able to upload to a server, and the server can download on reque= st, a vendor’s mapping of “attack-id” to “attack-na= me” for the specific vendor “id”.  Then, whenever th= ere is telemetry information ”id” + “attack-id” need to be prov= ided, but much space can be saved by not having to also include “atta= ck-name”.

 

Second suggestion is that ̶= 0;attack-id” is an integer instead of a string to again save on space= in the telemetry data.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B9330314A1A69OPEXCAUBMA2corp_-- From nobody Wed Apr 29 02:10: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 5A5F93A09F0 for ; Wed, 29 Apr 2020 02:10:57 -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 pIdI0rVoJ-GW for ; Wed, 29 Apr 2020 02:10:54 -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 8D1113A09EA for ; Wed, 29 Apr 2020 02:10:53 -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 1jTijw-0005qr-07; Wed, 29 Apr 2020 10:10:48 +0100 From: "Jon Shallow" To: , References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 29 Apr 2020 10:10:55 +0100 Message-ID: <02e901d61e06$169244d0$43b6ce70$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EA_01D61E0E.7859BA10" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLAgiedYICVX/EVKf7lEZA Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 09:10:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02EA_01D61E0E.7859BA10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 Please see inline Jon> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 April 2020 09:53 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon,=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 avril 2020 21:24 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 I was not thinking of dropping attack-name. I was more thinking of uploading / downloading as appropriate the entire list of id->attack-id<->attack-name. The attack-id<->attack-name list will = evolve over time so there will need to be a mechanism of doing updates, or signalling that there are new attack-id in use. [Med] I understood that. I was commenting on the implication on the = module.=20 Jon> Sure =20 Putting aside defining attack-id as an integer, I thought your proposal would be as follows (with removing attack-name from the attack-detail).=20 =20 +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id string | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] =85 +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 =85 =20 I was suggesting to leave the name under attack-detail but use it only = when an attack-id/name mapping is not already shared with the peer. The = structure would be as follows: =20 +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id uint32 | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] =85 +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id uint32 Jon> I see this is now an integer +--rw attack-name? string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 =85 =20 Please note that the examples we have in the draft do not include attack-name to insist that this is an optional attribute, e.g., Jon> Agreed =96 however =93an-id=94 needs to be made more human readable = at some point. =3D=3D "attack-detail": [ { "attack-id": "an-id", "start-time": "1957811234", "attack-severity": "emergency" } ] =3D=3D =20 However, the first time that an attack-id is used, the attack-name can = also be included. [Med] That=92s better. My suggestion goes a little bit further: the name = will be used till the mapping table is updated. =20 Jon> I am beginning to think that vendor-id should be a key as well as attack-id, as attack-id could be the same across multiple vendors but = mean different things. =20 Two immediate issues that come to mind are=20 =93What happens if the telemetry information packet that contains the attack-name gets lost in transit=94 [Med] We don=92t have this issue with the proposal above. Jon> Agreed until attack mapping has been refreshed =96 which has the potential to fail when not in peace time. Jon> Does the mapping refresh want to be done over the data channel as = it could be quite large? =20 =93If a major attack kicks off with many vectors, all of the attack-ids = for the first time, there will be a lot of traffic=94 =20 [Med] Removing attack-name does not eliminate this risk. The discussion = we had about block2/4 or managing this at the DOTS layer applies here. Jon> Agreed. However if the attack mapping is in place, there will be a = lot less data which would potentially ease the issue. ~Jon =20 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 16:57 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Re-,=20 =20 If attack-name is completely removed for the attack-details, this means = the remote peer can=92t make use of the information till the list is = refreshed.=20 =20 Isn=92t better to maintain the attribute as in the current design but an = agent uses this attribute only for new attacks?=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 To give an example for =93attack-id=94 and =93attack-name=94 the DDOS = Mitigator that I work with has several components that identify the same attack =20 Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: =93TCP Attack - Syn Flood" =20 And in the code I was using the index for =93attack-id=94 and the Descriptive-Name for the =93attack-name=94 for the recent telemetry = Interop with Kaname. =20 With a multi-vector attack, the descriptive name information was a substantive part of the telemetry information being passed back to the client. =20 Similarly, if the DDoS Mitigator was to act as a client to an upstream = DOTS server (which in my case it can), then again there is a lot of = information being relayed that could be reduced with a mapping between=94 = attack-id=94 and =93attack-name=94 for a specific vendor =93id=94 being uploaded ahead of = time =96 and can be refreshed if new attacks are discovered and mitigated. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon, =20 Apologies for the delay to follow on this one.=20 =20 attack-name is more about a description than a name. This field may also = be used to map attack details from distinct vendors because there is no a global registry (and we don=92t want to create one).=20 =20 Having the ability to retrieve a list prior to an attack is interesting = to consider but the (optional) attribute may still be needed to be included = for new attack types.=20 =20 Note that the name attribute is also used by a DOTS client to send = telemetry to a DOTS server.=20 =20 Attack-id is defined as a string because we inspired from existing event notification formats. Some of these formats allow for an even ID to be integer or string.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 Any thoughts on this data reduction? =20 While it is possible for a Vendor to come up with their own augmented = YANG to cover their vendor specifics, it gets problematic when 2 or more = Vendor specifics need to be understood by a client or a server. =20 Having a =93/vendor-mapping=94 operation path means that vendor mapping = of =93attack-id=94 and =93attack-name=94 can easily be exchanged. =20 If =93attack-id=94 is an integer instead of a string, then = =93attack-id=94 could become a Vendor specific set of enums (they do not need to start from 1) based on =93id=94. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 When passing telemetry attack information back and forth, there are some ways that we need to consider on data reduction, thus reducing the likelihood of having to do Block transfers. =20 My understanding is that there is a one-to-one relationship between =93attack-id=94 and =93attack-name=94. =20 My first suggestion is that the client is able to upload to a server, = and the server can download on request, a vendor=92s mapping of = =93attack-id=94 to =93attack-name=94 for the specific vendor =93id=94. Then, whenever = there is telemetry information =94id=94 + =93attack-id=94 need to be provided, = but much space can be saved by not having to also include =93attack-name=94. =20 Second suggestion is that =93attack-id=94 is an integer instead of a = string to again save on space in the telemetry data. =20 Regards =20 Jon ------=_NextPart_000_02EA_01D61E0E.7859BA10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Please see inline = Jon>

 

Regards

 

Jon

 

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

 

Hi Jon, =

 

Please see inline.

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 28 avril 2020 21:24
=C0 : BOUCADAIR Mohamed = TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry = draft: Vendor Specific data = reduction

 

Hi Med,

 

I was not thinking of = dropping attack-name.  I was more thinking of uploading / = downloading as appropriate the entire list of = id->attack-id<->attack-name.  The = attack-id<->attack-name list will evolve over time so there will = need to be a mechanism of doing updates, or signalling that there are = new attack-id in use.

[Med] I understood that. I was commenting on the = implication on the module.

Jon> = Sure

 

Putting aside defining attack-id as an integer, I = thought your proposal would be as follows (with removing attack-name = from the attack-detail).

 

    +--:(vendor-mapping) = {dots-telemetry}?

    |  +--rw attack-detail* = [attack-id]

    |     +--rw = vendor-id?     uint32

    |     +--rw = attack-id      string

    |     +--rw = attack-name    string

    +--:(telemetry) = {dots-telemetry}?

       +--rw = pre-or-ongoing-mitigation* [cuid tmid]

          = …

          +--rw = attack-detail* [attack-id]

          &nb= sp;  +--rw = vendor-id?         = uint32

          &nb= sp;  +--rw = attack-id          = string

          &nb= sp;  +--rw attack-severity?   = attack-severity

          &nb= sp;  +--rw start-time?        = uint64

          &nb= sp;  +--rw = end-time?          = uint64

          &nb= sp;  …

 

I was suggesting to leave the name under = attack-detail but use it only when an attack-id/name mapping is not = already shared with the peer. The structure would be as = follows:

 

    +--:(vendor-mapping) = {dots-telemetry}?

    |  +--rw attack-detail* = [attack-id]

    |     +--rw = vendor-id?     uint32

    |     +--rw = attack-id      uint32

    |     +--rw = attack-name    string

    +--:(telemetry) = {dots-telemetry}?

       +--rw = pre-or-ongoing-mitigation* [cuid tmid]

          = …

          +--rw = attack-detail* [attack-id]

          &nb= sp;  +--rw = vendor-id?         = uint32

          &nb= sp;  +--rw = attack-id          = uint32

Jon> I see this is now an = integer

          &nb= sp;  +--rw attack-name?       = string

          &nb= sp;  +--rw attack-severity?   = attack-severity

          &nb= sp;  +--rw start-time?        = uint64

          &nb= sp;  +--rw = end-time?          = uint64

          &nb= sp;  …

 

Please note that the examples we have in the draft = do not include attack-name to insist that this is an optional attribute, = e.g.,

Jon> Agreed – = however “an-id” needs to be made more human readable at some = point.

=3D=3D

           = "attack-detail": [

           &= nbsp; {

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

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

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

           &= nbsp; }

           = ]

=3D=3D

 

However, the first time = that an attack-id is used, the attack-name can also be = included.

[Med] That’s = better. My suggestion goes a little bit further: the name will be used = till the mapping table is updated. =  

Jon> I am beginning to think that vendor-id = should be a key as well as attack-id, as attack-id could be the same = across multiple vendors but mean different = things.

 

  Two immediate = issues that come to mind are

“What happens if = the telemetry information packet that contains the attack-name gets lost = in transit”

[Med] We don’t = have this issue with the proposal above.

Jon> Agreed until = attack mapping has been refreshed – which has the potential to = fail when not in peace time.

Jon>=A0 Does the = mapping refresh want to be done over the data channel as it could be = quite large?

 

“If a major attack kicks off with many = vectors, all of the attack-ids for the first time, there will be a lot = of traffic”

 

[Med] Removing attack-name does not eliminate this = risk. The discussion we had about block2/4 or managing this at the DOTS = layer applies here.

Jon> Agreed.=A0 = However if the attack mapping is in place, there will be a lot less data = which would potentially ease the issue.

~Jon

 

 

Regards

 

Jon

 

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

 

Re-, =

 

If attack-name is completely removed for the = attack-details, this means the remote peer can’t make use of the = information till the list is refreshed.

 

Isn’t better to maintain the attribute as in = the current design but an agent uses this attribute only for new = attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed = TGI/OLN; = dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor = Specific data reduction

 

Hi = Med,

 

To give an example for = “attack-id” and “attack-name” the DDOS Mitigator = that I work with has several components that identify the same = attack

 

Index: = 3016

Short-Name: = tcpattack_synflood

Descriptive-Name: “TCP Attack - Syn = Flood"

 

And in the code I was = using the index for “attack-id” and the Descriptive-Name for = the “attack-name” for the recent telemetry Interop with = Kaname.

 

With a multi-vector = attack, the descriptive name information was a substantive part of the = telemetry information being passed back to the = client.

 

Similarly, if the DDoS = Mitigator was to act as a client to an upstream DOTS server (which in my = case it can), then again there is a lot of information being relayed = that could be reduced with a mapping between” attack-id” and = “attack-name” for a specific vendor “id” being = uploaded ahead of time – and can be refreshed if new attacks are = discovered and mitigated.

 

Regards

 

Jon

 

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

 

Hi = Jon,

 

Apologies for the delay to follow on this one. =

 

attack-name is more about a description than a name. = This field may also be used to map attack details from distinct vendors = because there is no a global registry (and we don’t want to create = one).

 

Having the ability to retrieve a list prior to an = attack is interesting to consider but the (optional) attribute may still = be needed to be included for new attack types.

 

Note that the name attribute is also used by a DOTS = client to send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired = from existing event notification formats. Some of these formats allow = for an even ID to be integer or string.

 

Cheers,

Med

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : mardi 28 avril 2020 = 10:29
=C0 : dots@ietf.org
Objet : Re: = [Dots] Telemetry draft: Vendor Specific data = reduction

 

Hi All,

 

Any thoughts on this = data reduction?

 

While it is possible for = a Vendor to come up with their own augmented YANG to cover their vendor = specifics, it gets problematic when 2 or more Vendor specifics need to = be understood by a client or a server.

 

Having a = “/vendor-mapping” operation path means that vendor mapping = of “attack-id” and “attack-name” can easily be = exchanged.

 

If = “attack-id” is an integer instead of a string, then = “attack-id” could become a Vendor specific set of enums = (they do not need to start from 1) based on = “id”.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: 23 April 2020 10:49
To: = dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific = data reduction

 

Hi = All,

 

When passing telemetry attack information back and = forth, there are some ways that we need to consider on data reduction, = thus reducing the likelihood of having to do Block = transfers.

 

My understanding is that there is a one-to-one = relationship between “attack-id” and = “attack-name”.

 

My first = suggestion is that the client is able to upload to a server, and the = server can download on request, a vendor’s mapping of = “attack-id” to “attack-name” for the specific = vendor “id”.  Then, whenever there is telemetry = information ”id” + “attack-id” need to be = provided, but much space can be saved by not having to also include = “attack-name”.

 

Second = suggestion is that “attack-id” is an integer instead of a = string to again save on space in the telemetry data.

 

Regards

 

Jon

<= /div>
------=_NextPart_000_02EA_01D61E0E.7859BA10-- From nobody Wed Apr 29 03:29:35 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 1D65F3A0BAF for ; Wed, 29 Apr 2020 03:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UunBRKnYyCDE for ; Wed, 29 Apr 2020 03:29:30 -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 D11003A0BAE for ; Wed, 29 Apr 2020 03:29:29 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 49Bvrl6hTdz8tPH; Wed, 29 Apr 2020 12:29:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588156167; bh=iIEUdsAIcobR4iA5Dgki7MxKshns8Sw9D+741MchldE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=DiaWeGVsackKUip0eVMgG6BmChOmYY37A40SiPJfwHobFgxbbKu284PP8tgVdHGZW C5zVwmOICER/ZVxzTdwMmDkBDrliLFSu3+MY75plhZfigWvD/qht5HgagULu/eJTok tzXjbuWriBSFRxItLNWJXf3i9h66v38VHcTBHSI6yGt5aYbPtaUJJg/kKfDTHY9Fh0 T8FGyUQwq/dEZkfOA0JRzajb0Dq9g9jRjwjeSMlthCwhZ6K5bW1Yh7ZCBNXTp4MQ5f /4h7C+rP2xXiyw7fek0sKtGMMfpQFyXGiNsFPeXlE/4IXg+uSPhcRvJ3xm+h/jOeRH fYaJLQqnyrgCQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 49Bvrl5hZCzCqkv; Wed, 29 Apr 2020 12:29:27 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLAgiedYICVX/EVKf7lEZAgAAORXA= Date: Wed, 29 Apr 2020 10:29:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314A1AF9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <02e901d61e06$169244d0$43b6ce70$@jpshallow.com> In-Reply-To: <02e901d61e06$169244d0$43b6ce70$@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_787AE7BB302AE849A7480A190F8B9330314A1AF9OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 10:29:34 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314A1AF9OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, We need to agree if the client has to share its mappings with the server as= well. The use of the data channel would make sense as id/name mapping is s= imilar to the alias handling functionality. Vendor-id should be a key too. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 29 avril 2020 11:11 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, Please see inline Jon> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 April 2020 09:53 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 avril 2020 21:24 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, I was not thinking of dropping attack-name. I was more thinking of uploadi= ng / downloading as appropriate the entire list of id->attack-id<->attack-n= ame. The attack-id<->attack-name list will evolve over time so there will = need to be a mechanism of doing updates, or signalling that there are new a= ttack-id in use. [Med] I understood that. I was commenting on the implication on the module. Jon> Sure Putting aside defining attack-id as an integer, I thought your proposal wou= ld be as follows (with removing attack-name from the attack-detail). +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id string | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] ... +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 ... I was suggesting to leave the name under attack-detail but use it only when= an attack-id/name mapping is not already shared with the peer. The structu= re would be as follows: +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id uint32 | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] ... +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id uint32 Jon> I see this is now an integer +--rw attack-name? string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 ... Please note that the examples we have in the draft do not include attack-na= me to insist that this is an optional attribute, e.g., Jon> Agreed - however "an-id" needs to be made more human readable at some = point. =3D=3D "attack-detail": [ { "attack-id": "an-id", "start-time": "1957811234", "attack-severity": "emergency" } ] =3D=3D However, the first time that an attack-id is used, the attack-name can also= be included. [Med] That's better. My suggestion goes a little bit further: the name will= be used till the mapping table is updated. Jon> I am beginning to think that vendor-id should be a key as well as atta= ck-id, as attack-id could be the same across multiple vendors but mean diff= erent things. Two immediate issues that come to mind are "What happens if the telemetry information packet that contains the attack-= name gets lost in transit" [Med] We don't have this issue with the proposal above. Jon> Agreed until attack mapping has been refreshed - which has the potenti= al to fail when not in peace time. Jon> Does the mapping refresh want to be done over the data channel as it = could be quite large? "If a major attack kicks off with many vectors, all of the attack-ids for t= he first time, there will be a lot of traffic" [Med] Removing attack-name does not eliminate this risk. The discussion we = had about block2/4 or managing this at the DOTS layer applies here. Jon> Agreed. However if the attack mapping is in place, there will be a lo= t less data which would potentially ease the issue. ~Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 28 April 2020 16:57 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Re-, If attack-name is completely removed for the attack-details, this means the= remote peer can't make use of the information till the list is refreshed. Isn't better to maintain the attribute as in the current design but an agen= t uses this attribute only for new attacks? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, To give an example for "attack-id" and "attack-name" the DDOS Mitigator tha= t I work with has several components that identify the same attack Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: "TCP Attack - Syn Flood" And in the code I was using the index for "attack-id" and the Descriptive-N= ame for the "attack-name" for the recent telemetry Interop with Kaname. With a multi-vector attack, the descriptive name information was a substant= ive part of the telemetry information being passed back to the client. Similarly, if the DDoS Mitigator was to act as a client to an upstream DOTS= server (which in my case it can), then again there is a lot of information= being relayed that could be reduced with a mapping between" attack-id" and= "attack-name" for a specific vendor "id" being uploaded ahead of time - an= d can be refreshed if new attacks are discovered and mitigated. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi Jon, Apologies for the delay to follow on this one. attack-name is more about a description than a name. This field may also be= used to map attack details from distinct vendors because there is no a glo= bal registry (and we don't want to create one). Having the ability to retrieve a list prior to an attack is interesting to = consider but the (optional) attribute may still be needed to be included fo= r new attack types. Note that the name attribute is also used by a DOTS client to send telemetr= y to a DOTS server. Attack-id is defined as a string because we inspired from existing event no= tification formats. Some of these formats allow for an even ID to be intege= r or string. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, Any thoughts on this data reduction? While it is possible for a Vendor to come up with their own augmented YANG = to cover their vendor specifics, it gets problematic when 2 or more Vendor = specifics need to be understood by a client or a server. Having a "/vendor-mapping" operation path means that vendor mapping of "att= ack-id" and "attack-name" can easily be exchanged. If "attack-id" is an integer instead of a string, then "attack-id" could be= come a Vendor specific set of enums (they do not need to start from 1) base= d on "id". Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, When passing telemetry attack information back and forth, there are some wa= ys that we need to consider on data reduction, thus reducing the likelihood= of having to do Block transfers. My understanding is that there is a one-to-one relationship between "attack= -id" and "attack-name". My first suggestion is that the client is able to upload to a server, and t= he server can download on request, a vendor's mapping of "attack-id" to "at= tack-name" for the specific vendor "id". Then, whenever there is telemetry= information "id" + "attack-id" need to be provided, but much space can be = saved by not having to also include "attack-name". Second suggestion is that "attack-id" is an integer instead of a string to = again save on space in the telemetry data. Regards Jon --_000_787AE7BB302AE849A7480A190F8B9330314A1AF9OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

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

 

Vendor-id should be a key too.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 29 avril 2020 11:11
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

Please = see inline 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 April 2020 09:53
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 avril 2020 21:24
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

I was n= ot thinking of dropping attack-name.  I was more thinking of uploading= / downloading as appropriate the entire list of id->attack-id<->a= ttack-name.  The attack-id<->attack-name list will evolve over time so there will need to be a mechanism of doing updates, or signal= ling that there are new attack-id in use.

[Med] I understood that. I was commentin= g on the implication on the module.

Jon>= Sure

 

Putting aside defining attack-id as an i= nteger, I thought your proposal would be as follows (with removing attack-n= ame from the attack-detail).

 

    +--= :(vendor-mapping) {dots-telemetry}?

    | = +--rw attack-detail* [attack-id]

    | =     +--rw vendor-id?     uint32=

    | =     +--rw attack-id      string=

    | =     +--rw attack-name    string

    +--= :(telemetry) {dots-telemetry}?

    &n= bsp;  +--rw pre-or-ongoing-mitigation* [cuid tmid]

    &n= bsp;     …

    &n= bsp;     +--rw attack-detail* [attack-id]

    &n= bsp;        +--rw vendor-id? &n= bsp;       uint32

    &n= bsp;        +--rw attack-id &nb= sp;        string

    &n= bsp;        +--rw attack-severity?&n= bsp;  attack-severity

    &n= bsp;        +--rw start-time? &= nbsp;      uint64

    &n= bsp;        +--rw end-time? &nb= sp;        uint64

    &n= bsp;        …

 

I was suggesting to leave the name under attac= k-detail but use it only when an attack-id/name mapping is not already shar= ed with the peer. The structure would be as follows:

 

    +--= :(vendor-mapping) {dots-telemetry}?

    | = +--rw attack-detail* [attack-id]

    | =     +--rw vendor-id?     uint32=

    | =     +--rw attack-id      uint32=

    | =     +--rw attack-name    string

    +--= :(telemetry) {dots-telemetry}?

    &n= bsp;  +--rw pre-or-ongoing-mitigation* [cuid tmid]

    &n= bsp;     …

    &n= bsp;     +--rw attack-detail* [attack-id]

    &n= bsp;        +--rw vendor-id? &n= bsp;       uint32

    &n= bsp;        +--rw attack-id &nb= sp;        uint32

Jon> I see this is now an integer

    &n= bsp;        +--rw attack-name? =       string

    &n= bsp;        +--rw attack-severity?&n= bsp;  attack-severity

    &n= bsp;        +--rw start-time? &= nbsp;      uint64

    &n= bsp;        +--rw end-time? &nb= sp;        uint64

    &n= bsp;        …

 

Please note that the examples we have in the draft do not inc= lude attack-name to insist that this is an optional attribute, e.g.,

Jon> Agreed – however “an-id” needs to b= e made more human readable at some point.

=3D=3D

         &nbs= p; "attack-detail": [

         &nbs= p;   {

         &nbs= p;     "attack-id": "an-id",

         &nbs= p;     "start-time": "1957811234",<= o:p>

         &nbs= p;     "attack-severity": "emergency&quo= t;

         &nbs= p;   }

         &nbs= p; ]

=3D=3D

&n= bsp;

However= , the first time that an attack-id is used, the attack-name can also be inc= luded.

[Med] That’s better. My suggestion= goes a little bit further: the name will be used till the mapping table is= updated.  

Jon>= I am beginning to think that vendor-id should be a key as well as attack-i= d, as attack-id could be the same across multiple vendors but mean differen= t things.

 

  = Two immediate issues that come to mind are

“= What happens if the telemetry information packet that contains the attack-n= ame gets lost in transit”

[Med] We don’t have this issue wit= h the proposal above.

Jon>= Agreed until attack mapping has been refreshed – which has the poten= tial to fail when not in peace time.

Jon>=   Does the mapping refresh want to be done over the data channel as it= could be quite large?

 

“= If a major attack kicks off with many vectors, all of the attack-ids for th= e first time, there will be a lot of traffic”

&n= bsp;

[Med] Removing attack-name does not elim= inate this risk. The discussion we had about block2/4 or managing this at t= he DOTS layer applies here.

Jon>= Agreed.  However if the attack mapping is in place, there will be a l= ot less data which would potentially ease the issue.

~Jon

 

 

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 16:57
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Re-,

 

If attack-name is completely removed for the attack-details, = this means the remote peer can’t make use of the information till the= list is refreshed.

 

Isn’t better to maintain the attribute as in the curren= t design but an agent uses this attribute only for new attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed TGI/OLN;= dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

To give= an example for “attack-id” and “attack-name” the D= DOS Mitigator that I work with has several components that identify the sam= e attack

&n= bsp;

Index: = 3016

Short-N= ame: tcpattack_synflood

Descrip= tive-Name: “TCP Attack - Syn Flood"

&n= bsp;

And in = the code I was using the index for “attack-id” and the Descript= ive-Name for the “attack-name” for the recent telemetry Interop= with Kaname.

&n= bsp;

With a = multi-vector attack, the descriptive name information was a substantive par= t of the telemetry information being passed back to the client.<= /span>

&n= bsp;

Similar= ly, if the DDoS Mitigator was to act as a client to an upstream DOTS server= (which in my case it can), then again there is a lot of information being = relayed that could be reduced with a mapping between” attack-id” and “attack-name” for a specif= ic vendor “id” being uploaded ahead of time – and can be = refreshed if new attacks are discovered and mitigated.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 12:00
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Hi Jon,

 

Apologies for the delay to follow on this one.

 

attack-name is more about a description than a name. This fie= ld may also be used to map attack details from distinct vendors because the= re is no a global registry (and we don’t want to create one).

 

Having the ability to retrieve a list prior to an attack is i= nteresting to consider but the (optional) attribute may still be needed to = be included for new attack types.

 

Note that the name attribute is also used by a DOTS client to= send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired from exi= sting event notification formats. Some of these formats allow for an even I= D to be integer or string.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mardi 28 avril 2020 10:29
=C0 : dots@ietf.org
Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi All,=

&n= bsp;

Any tho= ughts on this data reduction?

&n= bsp;

While i= t is possible for a Vendor to come up with their own augmented YANG to cove= r their vendor specifics, it gets problematic when 2 or more Vendor specifi= cs need to be understood by a client or a server.

&n= bsp;

Having = a “/vendor-mapping” operation path means that vendor mapping of= “attack-id” and “attack-name” can easily be exchan= ged.

&n= bsp;

If R= 20;attack-id” is an integer instead of a string, then “attack-i= d” could become a Vendor specific set of enums (they do not need to s= tart from 1) based on “id”.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific data reduction=

 

Hi All,

 

When passing telemetry attack i= nformation back and forth, there are some ways that we need to consider on = data reduction, thus reducing the likelihood of having to do Block transfer= s.

 

My understanding is that there = is a one-to-one relationship between “attack-id” and “att= ack-name”.

 

My first suggestion is that the= client is able to upload to a server, and the server can download on reque= st, a vendor’s mapping of “attack-id” to “attack-na= me” for the specific vendor “id”.  Then, whenever th= ere is telemetry information ”id” + “attack-id” need to be prov= ided, but much space can be saved by not having to also include “atta= ck-name”.

 

Second suggestion is that ̶= 0;attack-id” is an integer instead of a string to again save on space= in the telemetry data.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B9330314A1AF9OPEXCAUBMA2corp_-- From nobody Wed Apr 29 03:45: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 AD0B23A0BFF for ; Wed, 29 Apr 2020 03:45:37 -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 wZx-2RvW7LkS for ; Wed, 29 Apr 2020 03:45:34 -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 0EBE33A0BF5 for ; Wed, 29 Apr 2020 03:45:33 -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 1jTkDb-0005uM-P7; Wed, 29 Apr 2020 11:45:32 +0100 From: "Jon Shallow" To: , References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <02e901d61e06$169244d0$43b6ce70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1AF9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314A1AF9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 29 Apr 2020 11:45:38 +0100 Message-ID: <031a01d61e13$52554460$f6ffcd20$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_01D61E1B.B41CB9A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLAgiedYICVX/EVAFMNLHJApZBsHin3JyooA== Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 10:45:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_031B_01D61E1B.B41CB9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is my belief that the client should share the mappings with the = server as well, even though the server may actually have the mappings because the server is supplied by the same vendor. =20 There is no harm on the server reporting any differences =96 there is = the possibility that 2 clients have 2 different mitigator release versions though what the client does with the differences (other than log them), = I am not sure. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 April 2020 11:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Re-, =20 We need to agree if the client has to share its mappings with the server = as well. The use of the data channel would make sense as id/name mapping is similar to the alias handling functionality. =20 Vendor-id should be a key too. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mercredi 29 avril 2020 11:11 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 Please see inline Jon> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 April 2020 09:53 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon,=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 avril 2020 21:24 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 I was not thinking of dropping attack-name. I was more thinking of uploading / downloading as appropriate the entire list of id->attack-id<->attack-name. The attack-id<->attack-name list will = evolve over time so there will need to be a mechanism of doing updates, or signalling that there are new attack-id in use. [Med] I understood that. I was commenting on the implication on the = module.=20 Jon> Sure =20 Putting aside defining attack-id as an integer, I thought your proposal would be as follows (with removing attack-name from the attack-detail).=20 =20 +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id string | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] =85 +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 =85 =20 I was suggesting to leave the name under attack-detail but use it only = when an attack-id/name mapping is not already shared with the peer. The = structure would be as follows: =20 +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id uint32 | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] =85 +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id uint32 Jon> I see this is now an integer +--rw attack-name? string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 =85 =20 Please note that the examples we have in the draft do not include attack-name to insist that this is an optional attribute, e.g., Jon> Agreed =96 however =93an-id=94 needs to be made more human readable = at some point. =3D=3D "attack-detail": [ { "attack-id": "an-id", "start-time": "1957811234", "attack-severity": "emergency" } ] =3D=3D =20 However, the first time that an attack-id is used, the attack-name can = also be included. [Med] That=92s better. My suggestion goes a little bit further: the name = will be used till the mapping table is updated. =20 Jon> I am beginning to think that vendor-id should be a key as well as attack-id, as attack-id could be the same across multiple vendors but = mean different things. =20 Two immediate issues that come to mind are=20 =93What happens if the telemetry information packet that contains the attack-name gets lost in transit=94 [Med] We don=92t have this issue with the proposal above. Jon> Agreed until attack mapping has been refreshed =96 which has the potential to fail when not in peace time. Jon> Does the mapping refresh want to be done over the data channel as = it could be quite large? =20 =93If a major attack kicks off with many vectors, all of the attack-ids = for the first time, there will be a lot of traffic=94 =20 [Med] Removing attack-name does not eliminate this risk. The discussion = we had about block2/4 or managing this at the DOTS layer applies here. Jon> Agreed. However if the attack mapping is in place, there will be a = lot less data which would potentially ease the issue. ~Jon =20 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 16:57 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Re-,=20 =20 If attack-name is completely removed for the attack-details, this means = the remote peer can=92t make use of the information till the list is = refreshed.=20 =20 Isn=92t better to maintain the attribute as in the current design but an = agent uses this attribute only for new attacks?=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 To give an example for =93attack-id=94 and =93attack-name=94 the DDOS = Mitigator that I work with has several components that identify the same attack =20 Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: =93TCP Attack - Syn Flood" =20 And in the code I was using the index for =93attack-id=94 and the Descriptive-Name for the =93attack-name=94 for the recent telemetry = Interop with Kaname. =20 With a multi-vector attack, the descriptive name information was a substantive part of the telemetry information being passed back to the client. =20 Similarly, if the DDoS Mitigator was to act as a client to an upstream = DOTS server (which in my case it can), then again there is a lot of = information being relayed that could be reduced with a mapping between=94 = attack-id=94 and =93attack-name=94 for a specific vendor =93id=94 being uploaded ahead of = time =96 and can be refreshed if new attacks are discovered and mitigated. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon, =20 Apologies for the delay to follow on this one.=20 =20 attack-name is more about a description than a name. This field may also = be used to map attack details from distinct vendors because there is no a global registry (and we don=92t want to create one).=20 =20 Having the ability to retrieve a list prior to an attack is interesting = to consider but the (optional) attribute may still be needed to be included = for new attack types.=20 =20 Note that the name attribute is also used by a DOTS client to send = telemetry to a DOTS server.=20 =20 Attack-id is defined as a string because we inspired from existing event notification formats. Some of these formats allow for an even ID to be integer or string.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 Any thoughts on this data reduction? =20 While it is possible for a Vendor to come up with their own augmented = YANG to cover their vendor specifics, it gets problematic when 2 or more = Vendor specifics need to be understood by a client or a server. =20 Having a =93/vendor-mapping=94 operation path means that vendor mapping = of =93attack-id=94 and =93attack-name=94 can easily be exchanged. =20 If =93attack-id=94 is an integer instead of a string, then = =93attack-id=94 could become a Vendor specific set of enums (they do not need to start from 1) based on =93id=94. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 When passing telemetry attack information back and forth, there are some ways that we need to consider on data reduction, thus reducing the likelihood of having to do Block transfers. =20 My understanding is that there is a one-to-one relationship between =93attack-id=94 and =93attack-name=94. =20 My first suggestion is that the client is able to upload to a server, = and the server can download on request, a vendor=92s mapping of = =93attack-id=94 to =93attack-name=94 for the specific vendor =93id=94. Then, whenever = there is telemetry information =94id=94 + =93attack-id=94 need to be provided, = but much space can be saved by not having to also include =93attack-name=94. =20 Second suggestion is that =93attack-id=94 is an integer instead of a = string to again save on space in the telemetry data. =20 Regards =20 Jon ------=_NextPart_000_031B_01D61E1B.B41CB9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is my belief that the client should share the = mappings with the server as well, even though the server may actually = have the mappings because the server is supplied by the same = vendor.

 

There is no harm on the = server reporting any differences – there is the possibility that 2 = clients have 2 different mitigator release versions though what the = client does with the differences (other than log them), I am not = sure.

 

Regards

 

Jon

 

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

 

Re-,

 

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

 

Vendor-id should be a key = too.

 

Cheers,

Med

 

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

 

Hi Med,

 

Please see inline = Jon>

 

Regards

 

Jon

 

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

 

Hi Jon, =

 

Please see inline.

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 28 avril 2020 21:24
=C0 : BOUCADAIR Mohamed = TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry = draft: Vendor Specific data = reduction

 

Hi Med,

 

I was not thinking of = dropping attack-name.  I was more thinking of uploading / = downloading as appropriate the entire list of = id->attack-id<->attack-name.  The = attack-id<->attack-name list will evolve over time so there will = need to be a mechanism of doing updates, or signalling that there are = new attack-id in use.

[Med] I understood that. I was commenting on the = implication on the module.

Jon> = Sure

 

Putting aside defining attack-id as an integer, I = thought your proposal would be as follows (with removing attack-name = from the attack-detail).

 

    +--:(vendor-mapping) = {dots-telemetry}?

    |  +--rw attack-detail* = [attack-id]

    |     +--rw = vendor-id?     uint32

    |     +--rw = attack-id      string

    |     +--rw = attack-name    string

    +--:(telemetry) = {dots-telemetry}?

       +--rw = pre-or-ongoing-mitigation* [cuid tmid]

          = …

          +--rw = attack-detail* [attack-id]

          &nb= sp;  +--rw = vendor-id?         = uint32

          &nb= sp;  +--rw = attack-id          = string

          &nb= sp;  +--rw attack-severity?   = attack-severity

          &nb= sp;  +--rw start-time?        = uint64

          &nb= sp;  +--rw = end-time?          = uint64

          &nb= sp;  …

 

I was suggesting to leave the name under = attack-detail but use it only when an attack-id/name mapping is not = already shared with the peer. The structure would be as = follows:

 

    +--:(vendor-mapping) = {dots-telemetry}?

    |  +--rw attack-detail* = [attack-id]

    |     +--rw = vendor-id?     uint32

    |     +--rw = attack-id      uint32

    |     +--rw = attack-name    string

    +--:(telemetry) = {dots-telemetry}?

       +--rw = pre-or-ongoing-mitigation* [cuid tmid]

          = …

          +--rw = attack-detail* [attack-id]

          &nb= sp;  +--rw = vendor-id?         = uint32

          &nb= sp;  +--rw = attack-id          = uint32

Jon> I see this is now an = integer

          &nb= sp;  +--rw attack-name?       = string

          &nb= sp;  +--rw attack-severity?   = attack-severity

          &nb= sp;  +--rw start-time?        = uint64

          &nb= sp;  +--rw = end-time?          = uint64

          &nb= sp;  …

 

Please note that the examples we have in the draft = do not include attack-name to insist that this is an optional attribute, = e.g.,

Jon> Agreed – = however “an-id” needs to be made more human readable at some = point.

=3D=3D

           = "attack-detail": [

           &= nbsp; {

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

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

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

           &= nbsp; }

           = ]

=3D=3D

 

However, the first time = that an attack-id is used, the attack-name can also be = included.

[Med] That’s = better. My suggestion goes a little bit further: the name will be used = till the mapping table is updated. =  

Jon> I am beginning to think that vendor-id = should be a key as well as attack-id, as attack-id could be the same = across multiple vendors but mean different = things.

 

  Two immediate = issues that come to mind are

“What happens if = the telemetry information packet that contains the attack-name gets lost = in transit”

[Med] We don’t = have this issue with the proposal above.

Jon> Agreed until = attack mapping has been refreshed – which has the potential to = fail when not in peace time.

Jon>  Does the = mapping refresh want to be done over the data channel as it could be = quite large?

 

“If a major attack kicks off with many = vectors, all of the attack-ids for the first time, there will be a lot = of traffic”

 

[Med] Removing attack-name does not eliminate this = risk. The discussion we had about block2/4 or managing this at the DOTS = layer applies here.

Jon> Agreed.  = However if the attack mapping is in place, there will be a lot less data = which would potentially ease the issue.

~Jon

 

 

Regards

 

Jon

 

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

 

Re-, =

 

If attack-name is completely removed for the = attack-details, this means the remote peer can’t make use of the = information till the list is refreshed.

 

Isn’t better to maintain the attribute as in = the current design but an agent uses this attribute only for new = attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed = TGI/OLN; = dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor = Specific data reduction

 

Hi = Med,

 

To give an example for = “attack-id” and “attack-name” the DDOS Mitigator = that I work with has several components that identify the same = attack

 

Index: = 3016

Short-Name: = tcpattack_synflood

Descriptive-Name: “TCP Attack - Syn = Flood"

 

And in the code I was = using the index for “attack-id” and the Descriptive-Name for = the “attack-name” for the recent telemetry Interop with = Kaname.

 

With a multi-vector = attack, the descriptive name information was a substantive part of the = telemetry information being passed back to the = client.

 

Similarly, if the DDoS = Mitigator was to act as a client to an upstream DOTS server (which in my = case it can), then again there is a lot of information being relayed = that could be reduced with a mapping between” attack-id” and = “attack-name” for a specific vendor “id” being = uploaded ahead of time – and can be refreshed if new attacks are = discovered and mitigated.

 

Regards

 

Jon

 

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

 

Hi = Jon,

 

Apologies for the delay to follow on this one. =

 

attack-name is more about a description than a name. = This field may also be used to map attack details from distinct vendors = because there is no a global registry (and we don’t want to create = one).

 

Having the ability to retrieve a list prior to an = attack is interesting to consider but the (optional) attribute may still = be needed to be included for new attack types.

 

Note that the name attribute is also used by a DOTS = client to send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired = from existing event notification formats. Some of these formats allow = for an even ID to be integer or string.

 

Cheers,

Med

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : mardi 28 avril 2020 = 10:29
=C0 : dots@ietf.org
Objet : Re: = [Dots] Telemetry draft: Vendor Specific data = reduction

 

Hi All,

 

Any thoughts on this = data reduction?

 

While it is possible for = a Vendor to come up with their own augmented YANG to cover their vendor = specifics, it gets problematic when 2 or more Vendor specifics need to = be understood by a client or a server.

 

Having a = “/vendor-mapping” operation path means that vendor mapping = of “attack-id” and “attack-name” can easily be = exchanged.

 

If = “attack-id” is an integer instead of a string, then = “attack-id” could become a Vendor specific set of enums = (they do not need to start from 1) based on = “id”.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: 23 April 2020 10:49
To: = dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific = data reduction

 

Hi = All,

 

When passing telemetry attack information back and = forth, there are some ways that we need to consider on data reduction, = thus reducing the likelihood of having to do Block = transfers.

 

My understanding is that there is a one-to-one = relationship between “attack-id” and = “attack-name”.

 

My first = suggestion is that the client is able to upload to a server, and the = server can download on request, a vendor’s mapping of = “attack-id” to “attack-name” for the specific = vendor “id”.  Then, whenever there is telemetry = information ”id” + “attack-id” need to be = provided, but much space can be saved by not having to also include = “attack-name”.

 

Second = suggestion is that “attack-id” is an integer instead of a = string to again save on space in the telemetry data.

 

Regards

 

Jon

<= /div>
------=_NextPart_000_031B_01D61E1B.B41CB9A0-- From nobody Wed Apr 29 04:36: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 2C1FF3A0D31 for ; Wed, 29 Apr 2020 04:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tROeqowYJprV for ; Wed, 29 Apr 2020 04:36:40 -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 EA9573A0D33 for ; Wed, 29 Apr 2020 04:36:38 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 49BxLD5Fvcz8tMt; Wed, 29 Apr 2020 13:36:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588160196; bh=v0sSCjsg3IXZGdz9OhyI0jg7yBuBZUhhlCz2L87/9hw=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=BEv0CHqnKxsXWZ78ePFD2+JQ55PraqMUV+sINwvWvT94Qmq1qqZJKkRgg/QpSA9bu ir4CtlLPbkzQKe5wrNtC9SJmylaph2ySuZd7S+7/remZfVAc4lEuA6OWMH6XrFbFGf gA04lyaNIzMWAhs/pqY0lilOtWmOvgqxBxIkMzIRChtgPsw+0u8znrl8Vv3EwYk2FA hSwZG8JYj1ffx2zGIOvNYLON1YarbBrdLWXOWjZfRTEjP1d2IP0boNkTRP/vFPzhbK Vl3f43SxnQqCoGdE7wM+rquMgidAQIjZb0hUy9UuznVUt1R9taAQyEdRetkjIBYDEE xTRpcdTYWzPfQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 49BxLD4Hn2zBrLr; Wed, 29 Apr 2020 13:36:36 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLAgiedYICVX/EVAFMNLHJApZBsHin3JyooIAACQYQ Date: Wed, 29 Apr 2020 11:36:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314A1B9C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <02e901d61e06$169244d0$43b6ce70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1AF9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031a01d61e13$52554460$f6ffcd20$@jpshallow.com> In-Reply-To: <031a01d61e13$52554460$f6ffcd20$@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_787AE7BB302AE849A7480A190F8B9330314A1B9COPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 11:36:44 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314A1B9COPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, The augment to the data channel would be: augment /ietf-data:dots-data/ietf-data:dots-client: +--rw vendor-mapping {dots-telemetry}? +--rw attack-detail* [vendor-id attack-id] +--rw vendor-id uint32 +--rw attack-id string +--rw attack-name string augment /ietf-data:dots-data/ietf-data:capabilities: +--ro vendor-mapping {dots-telemetry}? +--ro attack-detail* [vendor-id attack-id] +--ro vendor-id uint32 +--ro attack-id string +--ro attack-name string Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 29 avril 2020 12:46 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction It is my belief that the client should share the mappings with the server a= s well, even though the server may actually have the mappings because the s= erver is supplied by the same vendor. [Med] Not sure to understand the last part of your sentence. There is no harm on the server reporting any differences - there is the pos= sibility that 2 clients have 2 different mitigator release versions though = what the client does with the differences (other than log them), I am not s= ure. [Med] The mapping is per client, not per domain. A diff can't be interprete= d as a conflict. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 April 2020 11:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Re-, We need to agree if the client has to share its mappings with the server as= well. The use of the data channel would make sense as id/name mapping is s= imilar to the alias handling functionality. Vendor-id should be a key too. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 29 avril 2020 11:11 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, Please see inline Jon> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 April 2020 09:53 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 avril 2020 21:24 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, I was not thinking of dropping attack-name. I was more thinking of uploadi= ng / downloading as appropriate the entire list of id->attack-id<->attack-n= ame. The attack-id<->attack-name list will evolve over time so there will = need to be a mechanism of doing updates, or signalling that there are new a= ttack-id in use. [Med] I understood that. I was commenting on the implication on the module. Jon> Sure Putting aside defining attack-id as an integer, I thought your proposal wou= ld be as follows (with removing attack-name from the attack-detail). +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id string | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] ... +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 ... I was suggesting to leave the name under attack-detail but use it only when= an attack-id/name mapping is not already shared with the peer. The structu= re would be as follows: +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id uint32 | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] ... +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id uint32 Jon> I see this is now an integer +--rw attack-name? string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 ... Please note that the examples we have in the draft do not include attack-na= me to insist that this is an optional attribute, e.g., Jon> Agreed - however "an-id" needs to be made more human readable at some = point. =3D=3D "attack-detail": [ { "attack-id": "an-id", "start-time": "1957811234", "attack-severity": "emergency" } ] =3D=3D However, the first time that an attack-id is used, the attack-name can also= be included. [Med] That's better. My suggestion goes a little bit further: the name will= be used till the mapping table is updated. Jon> I am beginning to think that vendor-id should be a key as well as atta= ck-id, as attack-id could be the same across multiple vendors but mean diff= erent things. Two immediate issues that come to mind are "What happens if the telemetry information packet that contains the attack-= name gets lost in transit" [Med] We don't have this issue with the proposal above. Jon> Agreed until attack mapping has been refreshed - which has the potenti= al to fail when not in peace time. Jon> Does the mapping refresh want to be done over the data channel as it = could be quite large? "If a major attack kicks off with many vectors, all of the attack-ids for t= he first time, there will be a lot of traffic" [Med] Removing attack-name does not eliminate this risk. The discussion we = had about block2/4 or managing this at the DOTS layer applies here. Jon> Agreed. However if the attack mapping is in place, there will be a lo= t less data which would potentially ease the issue. ~Jon Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 28 April 2020 16:57 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Re-, If attack-name is completely removed for the attack-details, this means the= remote peer can't make use of the information till the list is refreshed. Isn't better to maintain the attribute as in the current design but an agen= t uses this attribute only for new attacks? Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, To give an example for "attack-id" and "attack-name" the DDOS Mitigator tha= t I work with has several components that identify the same attack Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: "TCP Attack - Syn Flood" And in the code I was using the index for "attack-id" and the Descriptive-N= ame for the "attack-name" for the recent telemetry Interop with Kaname. With a multi-vector attack, the descriptive name information was a substant= ive part of the telemetry information being passed back to the client. Similarly, if the DDoS Mitigator was to act as a client to an upstream DOTS= server (which in my case it can), then again there is a lot of information= being relayed that could be reduced with a mapping between" attack-id" and= "attack-name" for a specific vendor "id" being uploaded ahead of time - an= d can be refreshed if new attacks are discovered and mitigated. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi Jon, Apologies for the delay to follow on this one. attack-name is more about a description than a name. This field may also be= used to map attack details from distinct vendors because there is no a glo= bal registry (and we don't want to create one). Having the ability to retrieve a list prior to an attack is interesting to = consider but the (optional) attribute may still be needed to be included fo= r new attack types. Note that the name attribute is also used by a DOTS client to send telemetr= y to a DOTS server. Attack-id is defined as a string because we inspired from existing event no= tification formats. Some of these formats allow for an even ID to be intege= r or string. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, Any thoughts on this data reduction? While it is possible for a Vendor to come up with their own augmented YANG = to cover their vendor specifics, it gets problematic when 2 or more Vendor = specifics need to be understood by a client or a server. Having a "/vendor-mapping" operation path means that vendor mapping of "att= ack-id" and "attack-name" can easily be exchanged. If "attack-id" is an integer instead of a string, then "attack-id" could be= come a Vendor specific set of enums (they do not need to start from 1) base= d on "id". Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction Hi All, When passing telemetry attack information back and forth, there are some wa= ys that we need to consider on data reduction, thus reducing the likelihood= of having to do Block transfers. My understanding is that there is a one-to-one relationship between "attack= -id" and "attack-name". My first suggestion is that the client is able to upload to a server, and t= he server can download on request, a vendor's mapping of "attack-id" to "at= tack-name" for the specific vendor "id". Then, whenever there is telemetry= information "id" + "attack-id" need to be provided, but much space can be = saved by not having to also include "attack-name". Second suggestion is that "attack-id" is an integer instead of a string to = again save on space in the telemetry data. Regards Jon --_000_787AE7BB302AE849A7480A190F8B9330314A1B9COPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

The augment to the data channel would be:

 

  augment /ietf-data:= dots-data/ietf-data:dots-client:

    +--= rw vendor-mapping {dots-telemetry}?

    &n= bsp;  +--rw attack-detail* [vendor-id attack-id]=

    &n= bsp;     +--rw vendor-id    &nb= sp; uint32

    &n= bsp;     +--rw attack-id    &nb= sp; string

    &n= bsp;     +--rw attack-name    string=

  augment /ietf-data:= dots-data/ietf-data:capabilities:

    +--= ro vendor-mapping {dots-telemetry}?

    &n= bsp;  +--ro attack-detail* [vendor-id attack-id]=

    &n= bsp;     +--ro vendor-id    &nb= sp; uint32

    &n= bsp;     +--ro attack-id    &nb= sp; string

    &n= bsp;     +--ro attack-name    string=

 

Please see inline.

 

Cheers,

Med

 

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

 

It is m= y belief that the client should share the mappings with the server as well,= even though the server may actually have the mappings because the server i= s supplied by the same vendor.

[Med] Not sure to understand the last pa= rt of your sentence.

&n= bsp;

There i= s no harm on the server reporting any differences – there is the poss= ibility that 2 clients have 2 different mitigator release versions though w= hat the client does with the differences (other than log them), I am not sure.

[Med] The mapping is per client, not per= domain. A diff can’t be interpreted as a conflict.  =

&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 April 2020 11:29
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Re-,

 

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

 

Vendor-id should be a key too.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 29 avril 2020 11:11
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

Please = see inline 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 April 2020 09:53
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 avril 2020 21:24
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

I was n= ot thinking of dropping attack-name.  I was more thinking of uploading= / downloading as appropriate the entire list of id->attack-id<->a= ttack-name.  The attack-id<->attack-name list will evolve over time so there will need to be a mechanism of doing updates, or signal= ling that there are new attack-id in use.

[Med] I understood that. I was commentin= g on the implication on the module.

Jon>= Sure

 

Putting aside defining attack-id as an i= nteger, I thought your proposal would be as follows (with removing attack-n= ame from the attack-detail).

 

    +--= :(vendor-mapping) {dots-telemetry}?

    | = +--rw attack-detail* [attack-id]

    | =     +--rw vendor-id?     uint32=

    | =     +--rw attack-id      string=

    | =     +--rw attack-name    string

    +--= :(telemetry) {dots-telemetry}?

    &n= bsp;  +--rw pre-or-ongoing-mitigation* [cuid tmid]

    &n= bsp;     …

    &n= bsp;     +--rw attack-detail* [attack-id]

    &n= bsp;        +--rw vendor-id? &n= bsp;       uint32

    &n= bsp;        +--rw attack-id &nb= sp;        string

    &n= bsp;        +--rw attack-severity?&n= bsp;  attack-severity

    &n= bsp;        +--rw start-time? &= nbsp;      uint64

    &n= bsp;        +--rw end-time? &nb= sp;        uint64

    &n= bsp;        …

 

I was suggesting to leave the name under attac= k-detail but use it only when an attack-id/name mapping is not already shar= ed with the peer. The structure would be as follows:

 

    +--= :(vendor-mapping) {dots-telemetry}?

    | = +--rw attack-detail* [attack-id]

    | =     +--rw vendor-id?     uint32=

    | =     +--rw attack-id      uint32=

    | =     +--rw attack-name    string

    +--= :(telemetry) {dots-telemetry}?

    &n= bsp;  +--rw pre-or-ongoing-mitigation* [cuid tmid]

    &n= bsp;     …

    &n= bsp;     +--rw attack-detail* [attack-id]

    &n= bsp;        +--rw vendor-id? &n= bsp;       uint32

    &n= bsp;        +--rw attack-id &nb= sp;        uint32

Jon> I see this is now an integer

    &n= bsp;        +--rw attack-name? =       string

    &n= bsp;        +--rw attack-severity?&n= bsp;  attack-severity

    &n= bsp;        +--rw start-time? &= nbsp;      uint64

    &n= bsp;        +--rw end-time? &nb= sp;        uint64

    &n= bsp;        …

 

Please note that the examples we have in the draft do not inc= lude attack-name to insist that this is an optional attribute, e.g.,

Jon> Agreed – however “an-id” needs to b= e made more human readable at some point.

=3D=3D

         &nbs= p; "attack-detail": [

         &nbs= p;   {

         &nbs= p;     "attack-id": "an-id",

         &nbs= p;     "start-time": "1957811234",<= o:p>

         &nbs= p;     "attack-severity": "emergency&quo= t;

         &nbs= p;   }

         &nbs= p; ]

=3D=3D

&n= bsp;

However= , the first time that an attack-id is used, the attack-name can also be inc= luded.

[Med] That’s better. My suggestion= goes a little bit further: the name will be used till the mapping table is= updated.  

Jon>= I am beginning to think that vendor-id should be a key as well as attack-i= d, as attack-id could be the same across multiple vendors but mean differen= t things.

 

  = Two immediate issues that come to mind are

“= What happens if the telemetry information packet that contains the attack-n= ame gets lost in transit”

[Med] We don’t have this issue wit= h the proposal above.

Jon>= Agreed until attack mapping has been refreshed – which has the poten= tial to fail when not in peace time.

Jon>=   Does the mapping refresh want to be done over the data channel as it= could be quite large?

 

“= If a major attack kicks off with many vectors, all of the attack-ids for th= e first time, there will be a lot of traffic”

&n= bsp;

[Med] Removing attack-name does not elim= inate this risk. The discussion we had about block2/4 or managing this at t= he DOTS layer applies here.

Jon>= Agreed.  However if the attack mapping is in place, there will be a l= ot less data which would potentially ease the issue.

~Jon

 

 

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 16:57
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Re-,

 

If attack-name is completely removed for the attack-details, = this means the remote peer can’t make use of the information till the= list is refreshed.

 

Isn’t better to maintain the attribute as in the curren= t design but an agent uses this attribute only for new attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed TGI/OLN;= dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

To give= an example for “attack-id” and “attack-name” the D= DOS Mitigator that I work with has several components that identify the sam= e attack

&n= bsp;

Index: = 3016

Short-N= ame: tcpattack_synflood

Descrip= tive-Name: “TCP Attack - Syn Flood"

&n= bsp;

And in = the code I was using the index for “attack-id” and the Descript= ive-Name for the “attack-name” for the recent telemetry Interop= with Kaname.

&n= bsp;

With a = multi-vector attack, the descriptive name information was a substantive par= t of the telemetry information being passed back to the client.<= /span>

&n= bsp;

Similar= ly, if the DDoS Mitigator was to act as a client to an upstream DOTS server= (which in my case it can), then again there is a lot of information being = relayed that could be reduced with a mapping between” attack-id” and “attack-name” for a specif= ic vendor “id” being uploaded ahead of time – and can be = refreshed if new attacks are discovered and mitigated.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 28 April 2020 12:00
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Hi Jon,

 

Apologies for the delay to follow on this one.

 

attack-name is more about a description than a name. This fie= ld may also be used to map attack details from distinct vendors because the= re is no a global registry (and we don’t want to create one).

 

Having the ability to retrieve a list prior to an attack is i= nteresting to consider but the (optional) attribute may still be needed to = be included for new attack types.

 

Note that the name attribute is also used by a DOTS client to= send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired from exi= sting event notification formats. Some of these formats allow for an even I= D to be integer or string.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mardi 28 avril 2020 10:29
=C0 : dots@ietf.org
Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi All,=

&n= bsp;

Any tho= ughts on this data reduction?

&n= bsp;

While i= t is possible for a Vendor to come up with their own augmented YANG to cove= r their vendor specifics, it gets problematic when 2 or more Vendor specifi= cs need to be understood by a client or a server.

&n= bsp;

Having = a “/vendor-mapping” operation path means that vendor mapping of= “attack-id” and “attack-name” can easily be exchan= ged.

&n= bsp;

If R= 20;attack-id” is an integer instead of a string, then “attack-i= d” could become a Vendor specific set of enums (they do not need to s= tart from 1) based on “id”.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific data reduction=

 

Hi All,

 

When passing telemetry attack i= nformation back and forth, there are some ways that we need to consider on = data reduction, thus reducing the likelihood of having to do Block transfer= s.

 

My understanding is that there = is a one-to-one relationship between “attack-id” and “att= ack-name”.

 

My first suggestion is that the= client is able to upload to a server, and the server can download on reque= st, a vendor’s mapping of “attack-id” to “attack-na= me” for the specific vendor “id”.  Then, whenever th= ere is telemetry information ”id” + “attack-id” need to be prov= ided, but much space can be saved by not having to also include “atta= ck-name”.

 

Second suggestion is that ̶= 0;attack-id” is an integer instead of a string to again save on space= in the telemetry data.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B9330314A1B9COPEXCAUBMA2corp_-- From nobody Wed Apr 29 04:57:44 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 2E3F43A0D9A for ; Wed, 29 Apr 2020 04:57:41 -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 fYQV7xlfrGjO for ; Wed, 29 Apr 2020 04:57: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 EBBD03A0D98 for ; Wed, 29 Apr 2020 04:57:35 -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 1jTlLI-0005xz-Pa; Wed, 29 Apr 2020 12:57:33 +0100 From: "Jon Shallow" To: , References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <02e901d61e06$169244d0$43b6ce70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1AF9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031a01d61e13$52554460$f6ffcd20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1B9C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314A1B9C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 29 Apr 2020 12:57:39 +0100 Message-ID: <035601d61e1d$61d40ca0$257c25e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0357_01D61E25.C39D0880" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLAgiedYICVX/EVAFMNLHJApZBsHgCOgQTJAC9JjJup8T1C3A= Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 11:57:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0357_01D61E25.C39D0880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline Jon1> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 April 2020 12:37 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Re-,=20 =20 The augment to the data channel would be:=20 =20 augment /ietf-data:dots-data/ietf-data:dots-client: +--rw vendor-mapping {dots-telemetry}? +--rw attack-detail* [vendor-id attack-id] +--rw vendor-id uint32 +--rw attack-id string +--rw attack-name string augment /ietf-data:dots-data/ietf-data:capabilities: +--ro vendor-mapping {dots-telemetry}? +--ro attack-detail* [vendor-id attack-id] +--ro vendor-id uint32 +--ro attack-id string +--ro attack-name string =20 Please see inline.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mercredi 29 avril 2020 12:46 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 It is my belief that the client should share the mappings with the = server as well, even though the server may actually have the mappings because the server is supplied by the same vendor. [Med] Not sure to understand the last part of your sentence. =20 Jon1> If the server and client are provided by the same vendor, then = they will both know the vendor-id specific mappings so for the client to send them (or the server to respond to respond with them) is not necessarily needed, but is useful for consistency across all vendors. =20 There is no harm on the server reporting any differences =96 there is = the possibility that 2 clients have 2 different mitigator release versions though what the client does with the differences (other than log them), = I am not sure. [Med] The mapping is per client, not per domain. A diff can=92t be = interpreted as a conflict.=20 Jon1> Good thinking =96 not an issue. However, the client and server = from the same vendor may be on different code releases (or attack matching = details) and so there could be a difference (but I would have expected that one = of the mappings is a superset of the other, not with any replacements, but there may be local modifications =85.). However, if the client tells = the server, the server than updates its local, per client, mapping and only = uses that mapping for any reporting etc. Similarly, when the client pulls = back the server version of the mapping, it updates the active mapping table = to use for telemetry being sent by the server, but continues to use the = mapping tables it told the server for telemetry from client to server. ~Jon1 =20 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 April 2020 11:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Re-, =20 We need to agree if the client has to share its mappings with the server = as well. The use of the data channel would make sense as id/name mapping is similar to the alias handling functionality. =20 Vendor-id should be a key too. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mercredi 29 avril 2020 11:11 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 Please see inline Jon> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 29 April 2020 09:53 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon,=20 =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 avril 2020 21:24 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 I was not thinking of dropping attack-name. I was more thinking of uploading / downloading as appropriate the entire list of id->attack-id<->attack-name. The attack-id<->attack-name list will = evolve over time so there will need to be a mechanism of doing updates, or signalling that there are new attack-id in use. [Med] I understood that. I was commenting on the implication on the = module.=20 Jon> Sure =20 Putting aside defining attack-id as an integer, I thought your proposal would be as follows (with removing attack-name from the attack-detail).=20 =20 +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id string | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] =85 +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 =85 =20 I was suggesting to leave the name under attack-detail but use it only = when an attack-id/name mapping is not already shared with the peer. The = structure would be as follows: =20 +--:(vendor-mapping) {dots-telemetry}? | +--rw attack-detail* [attack-id] | +--rw vendor-id? uint32 | +--rw attack-id uint32 | +--rw attack-name string +--:(telemetry) {dots-telemetry}? +--rw pre-or-ongoing-mitigation* [cuid tmid] =85 +--rw attack-detail* [attack-id] +--rw vendor-id? uint32 +--rw attack-id uint32 Jon> I see this is now an integer +--rw attack-name? string +--rw attack-severity? attack-severity +--rw start-time? uint64 +--rw end-time? uint64 =85 =20 Please note that the examples we have in the draft do not include attack-name to insist that this is an optional attribute, e.g., Jon> Agreed =96 however =93an-id=94 needs to be made more human readable = at some point. =3D=3D "attack-detail": [ { "attack-id": "an-id", "start-time": "1957811234", "attack-severity": "emergency" } ] =3D=3D =20 However, the first time that an attack-id is used, the attack-name can = also be included. [Med] That=92s better. My suggestion goes a little bit further: the name = will be used till the mapping table is updated. =20 Jon> I am beginning to think that vendor-id should be a key as well as attack-id, as attack-id could be the same across multiple vendors but = mean different things. =20 Two immediate issues that come to mind are=20 =93What happens if the telemetry information packet that contains the attack-name gets lost in transit=94 [Med] We don=92t have this issue with the proposal above. Jon> Agreed until attack mapping has been refreshed =96 which has the potential to fail when not in peace time. Jon> Does the mapping refresh want to be done over the data channel as = it could be quite large? =20 =93If a major attack kicks off with many vectors, all of the attack-ids = for the first time, there will be a lot of traffic=94 =20 [Med] Removing attack-name does not eliminate this risk. The discussion = we had about block2/4 or managing this at the DOTS layer applies here. Jon> Agreed. However if the attack mapping is in place, there will be a = lot less data which would potentially ease the issue. ~Jon =20 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 16:57 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Re-,=20 =20 If attack-name is completely removed for the attack-details, this means = the remote peer can=92t make use of the information till the list is = refreshed.=20 =20 Isn=92t better to maintain the attribute as in the current design but an = agent uses this attribute only for new attacks?=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 avril 2020 17:16 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Med, =20 To give an example for =93attack-id=94 and =93attack-name=94 the DDOS = Mitigator that I work with has several components that identify the same attack =20 Index: 3016 Short-Name: tcpattack_synflood Descriptive-Name: =93TCP Attack - Syn Flood" =20 And in the code I was using the index for =93attack-id=94 and the Descriptive-Name for the =93attack-name=94 for the recent telemetry = Interop with Kaname. =20 With a multi-vector attack, the descriptive name information was a substantive part of the telemetry information being passed back to the client. =20 Similarly, if the DDoS Mitigator was to act as a client to an upstream = DOTS server (which in my case it can), then again there is a lot of = information being relayed that could be reduced with a mapping between=94 = attack-id=94 and =93attack-name=94 for a specific vendor =93id=94 being uploaded ahead of = time =96 and can be refreshed if new attacks are discovered and mitigated. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 April 2020 12:00 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi Jon, =20 Apologies for the delay to follow on this one.=20 =20 attack-name is more about a description than a name. This field may also = be used to map attack details from distinct vendors because there is no a global registry (and we don=92t want to create one).=20 =20 Having the ability to retrieve a list prior to an attack is interesting = to consider but the (optional) attribute may still be needed to be included = for new attack types.=20 =20 Note that the name attribute is also used by a DOTS client to send = telemetry to a DOTS server.=20 =20 Attack-id is defined as a string because we inspired from existing event notification formats. Some of these formats allow for an even ID to be integer or string.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mardi 28 avril 2020 10:29 =C0 : dots@ietf.org Objet : Re: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 Any thoughts on this data reduction? =20 While it is possible for a Vendor to come up with their own augmented = YANG to cover their vendor specifics, it gets problematic when 2 or more = Vendor specifics need to be understood by a client or a server. =20 Having a =93/vendor-mapping=94 operation path means that vendor mapping = of =93attack-id=94 and =93attack-name=94 can easily be exchanged. =20 If =93attack-id=94 is an integer instead of a string, then = =93attack-id=94 could become a Vendor specific set of enums (they do not need to start from 1) based on =93id=94. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 23 April 2020 10:49 To: dots@ietf.org Subject: [Dots] Telemetry draft: Vendor Specific data reduction =20 Hi All, =20 When passing telemetry attack information back and forth, there are some ways that we need to consider on data reduction, thus reducing the likelihood of having to do Block transfers. =20 My understanding is that there is a one-to-one relationship between =93attack-id=94 and =93attack-name=94. =20 My first suggestion is that the client is able to upload to a server, = and the server can download on request, a vendor=92s mapping of = =93attack-id=94 to =93attack-name=94 for the specific vendor =93id=94. Then, whenever = there is telemetry information =94id=94 + =93attack-id=94 need to be provided, = but much space can be saved by not having to also include =93attack-name=94. =20 Second suggestion is that =93attack-id=94 is an integer instead of a = string to again save on space in the telemetry data. =20 Regards =20 Jon ------=_NextPart_000_0357_01D61E25.C39D0880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = Jon1>

 

Regards

 

Jon

 

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

 

Re-, =

 

The augment to the data channel would be: =

 

  augment = /ietf-data:dots-data/ietf-data:dots-client:

    +--rw vendor-mapping = {dots-telemetry}?

       +--rw attack-detail* = [vendor-id attack-id]

          +--rw = vendor-id      uint32

          +--rw = attack-id      string

          +--rw = attack-name    string

  augment = /ietf-data:dots-data/ietf-data:capabilities:

    +--ro vendor-mapping = {dots-telemetry}?

       +--ro attack-detail* = [vendor-id attack-id]

          +--ro = vendor-id      uint32

          +--ro = attack-id      string

          +--ro = attack-name    string

 

Please see inline.

 

Cheers,

Med

 

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

 

It is my belief that the client should share the = mappings with the server as well, even though the server may actually = have the mappings because the server is supplied by the same = vendor.

[Med] Not sure to = understand the last part of your sentence.

 

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

 

There is no harm on the = server reporting any differences – there is the possibility that 2 = clients have 2 different mitigator release versions though what the = client does with the differences (other than log them), I am not = sure.

[Med] The mapping is = per client, not per domain. A diff can’t be interpreted as a = conflict.

Jon1> Good thinking = – not an issue.=A0 However, the client and server from the same = vendor may be on different code releases (or attack matching details) = and so there could be a difference (but I would have expected that one = of the mappings is a superset of the other, not with any replacements, = but there may be local modifications ….).=A0 However, if the = client tells the server, the server than updates its local, per client, = mapping and only uses that mapping for any reporting etc.=A0 Similarly, = =A0when the client pulls back the server version of the mapping, it = updates the active mapping table to use for telemetry being sent by the = server, but continues to use the mapping tables it told the server for = telemetry from client to server.

~Jon1

 

 

Regards

 

Jon

 

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

 

Re-,

 

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

 

Vendor-id should be a key = too.

 

Cheers,

Med

 

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

 

Hi Med,

 

Please see inline = Jon>

 

Regards

 

Jon

 

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

 

Hi Jon, =

 

Please see inline.

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 28 avril 2020 21:24
=C0 : BOUCADAIR Mohamed = TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry = draft: Vendor Specific data = reduction

 

Hi Med,

 

I was not thinking of = dropping attack-name.  I was more thinking of uploading / = downloading as appropriate the entire list of = id->attack-id<->attack-name.  The = attack-id<->attack-name list will evolve over time so there will = need to be a mechanism of doing updates, or signalling that there are = new attack-id in use.

[Med] I understood that. I was commenting on the = implication on the module.

Jon> = Sure

 

Putting aside defining attack-id as an integer, I = thought your proposal would be as follows (with removing attack-name = from the attack-detail).

 

    +--:(vendor-mapping) = {dots-telemetry}?

    |  +--rw attack-detail* = [attack-id]

    |     +--rw = vendor-id?     uint32

    |     +--rw = attack-id      string

    |     +--rw = attack-name    string

    +--:(telemetry) = {dots-telemetry}?

       +--rw = pre-or-ongoing-mitigation* [cuid tmid]

          = …

          +--rw = attack-detail* [attack-id]

          &nb= sp;  +--rw = vendor-id?         = uint32

          &nb= sp;  +--rw = attack-id          = string

          &nb= sp;  +--rw attack-severity?   = attack-severity

          &nb= sp;  +--rw start-time?        = uint64

          &nb= sp;  +--rw = end-time?          = uint64

          &nb= sp;  …

 

I was suggesting to leave the name under = attack-detail but use it only when an attack-id/name mapping is not = already shared with the peer. The structure would be as = follows:

 

    +--:(vendor-mapping) = {dots-telemetry}?

    |  +--rw attack-detail* = [attack-id]

    |     +--rw = vendor-id?     uint32

    |     +--rw = attack-id      uint32

    |     +--rw = attack-name    string

    +--:(telemetry) = {dots-telemetry}?

       +--rw = pre-or-ongoing-mitigation* [cuid tmid]

          = …

          +--rw = attack-detail* [attack-id]

          &nb= sp;  +--rw = vendor-id?         = uint32

          &nb= sp;  +--rw = attack-id          = uint32

Jon> I see this is now an = integer

          &nb= sp;  +--rw attack-name?       = string

          &nb= sp;  +--rw attack-severity?   = attack-severity

          &nb= sp;  +--rw start-time?        = uint64

          &nb= sp;  +--rw = end-time?          = uint64

          &nb= sp;  …

 

Please note that the examples we have in the draft = do not include attack-name to insist that this is an optional attribute, = e.g.,

Jon> Agreed – = however “an-id” needs to be made more human readable at some = point.

=3D=3D

           = "attack-detail": [

           &= nbsp; {

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

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

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

           &= nbsp; }

           = ]

=3D=3D

 

However, the first time = that an attack-id is used, the attack-name can also be = included.

[Med] That’s = better. My suggestion goes a little bit further: the name will be used = till the mapping table is updated. =  

Jon> I am beginning to think that vendor-id = should be a key as well as attack-id, as attack-id could be the same = across multiple vendors but mean different = things.

 

  Two immediate = issues that come to mind are

“What happens if = the telemetry information packet that contains the attack-name gets lost = in transit”

[Med] We don’t = have this issue with the proposal above.

Jon> Agreed until = attack mapping has been refreshed – which has the potential to = fail when not in peace time.

Jon>  Does the = mapping refresh want to be done over the data channel as it could be = quite large?

 

“If a major attack kicks off with many = vectors, all of the attack-ids for the first time, there will be a lot = of traffic”

 

[Med] Removing attack-name does not eliminate this = risk. The discussion we had about block2/4 or managing this at the DOTS = layer applies here.

Jon> Agreed.  = However if the attack mapping is in place, there will be a lot less data = which would potentially ease the issue.

~Jon

 

 

Regards

 

Jon

 

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

 

Re-, =

 

If attack-name is completely removed for the = attack-details, this means the remote peer can’t make use of the = information till the list is refreshed.

 

Isn’t better to maintain the attribute as in = the current design but an agent uses this attribute only for new = attacks?

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : = mardi 28 avril 2020 17:16
=C0 : BOUCADAIR Mohamed = TGI/OLN; = dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor = Specific data reduction

 

Hi = Med,

 

To give an example for = “attack-id” and “attack-name” the DDOS Mitigator = that I work with has several components that identify the same = attack

 

Index: = 3016

Short-Name: = tcpattack_synflood

Descriptive-Name: “TCP Attack - Syn = Flood"

 

And in the code I was = using the index for “attack-id” and the Descriptive-Name for = the “attack-name” for the recent telemetry Interop with = Kaname.

 

With a multi-vector = attack, the descriptive name information was a substantive part of the = telemetry information being passed back to the = client.

 

Similarly, if the DDoS = Mitigator was to act as a client to an upstream DOTS server (which in my = case it can), then again there is a lot of information being relayed = that could be reduced with a mapping between” attack-id” and = “attack-name” for a specific vendor “id” being = uploaded ahead of time – and can be refreshed if new attacks are = discovered and mitigated.

 

Regards

 

Jon

 

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

 

Hi = Jon,

 

Apologies for the delay to follow on this one. =

 

attack-name is more about a description than a name. = This field may also be used to map attack details from distinct vendors = because there is no a global registry (and we don’t want to create = one).

 

Having the ability to retrieve a list prior to an = attack is interesting to consider but the (optional) attribute may still = be needed to be included for new attack types.

 

Note that the name attribute is also used by a DOTS = client to send telemetry to a DOTS server.

 

Attack-id is defined as a string because we inspired = from existing event notification formats. Some of these formats allow = for an even ID to be integer or string.

 

Cheers,

Med

 

De : Dots = [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow
Envoy=E9 : mardi 28 avril 2020 = 10:29
=C0 : dots@ietf.org
Objet : Re: = [Dots] Telemetry draft: Vendor Specific data = reduction

 

Hi All,

 

Any thoughts on this = data reduction?

 

While it is possible for = a Vendor to come up with their own augmented YANG to cover their vendor = specifics, it gets problematic when 2 or more Vendor specifics need to = be understood by a client or a server.

 

Having a = “/vendor-mapping” operation path means that vendor mapping = of “attack-id” and “attack-name” can easily be = exchanged.

 

If = “attack-id” is an integer instead of a string, then = “attack-id” could become a Vendor specific set of enums = (they do not need to start from 1) based on = “id”.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: 23 April 2020 10:49
To: = dots@ietf.org
Subject: [Dots] Telemetry draft: Vendor Specific = data reduction

 

Hi = All,

 

When passing telemetry attack information back and = forth, there are some ways that we need to consider on data reduction, = thus reducing the likelihood of having to do Block = transfers.

 

My understanding is that there is a one-to-one = relationship between “attack-id” and = “attack-name”.

 

My first = suggestion is that the client is able to upload to a server, and the = server can download on request, a vendor’s mapping of = “attack-id” to “attack-name” for the specific = vendor “id”.  Then, whenever there is telemetry = information ”id” + “attack-id” need to be = provided, but much space can be saved by not having to also include = “attack-name”.

 

Second = suggestion is that “attack-id” is an integer instead of a = string to again save on space in the telemetry data.

 

Regards

 

Jon

<= /div>
------=_NextPart_000_0357_01D61E25.C39D0880--