From nobody Tue Oct 6 04:43: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 333FF3A03F4; Tue, 6 Oct 2020 04:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl7MsTvB12RU; Tue, 6 Oct 2020 04:43:12 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B183A141A; Tue, 6 Oct 2020 04:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vhqqUUAOW6rQUAg/uqO4Gin+cfPUwFg/yyWrvBsH2V4=; b=fWx3AEKKOmUDU8Q61HwztWi5d3 xWA3dXm+5G+Q6JgQfSxN48JML4PqdbOYOO9p2So6T7M7jOrER3jqsutyFHIVR0Ls8ctgrXVNYS4lE /gSBE/bXZewyaI0i7j7HPsQcIELpMkQkHZb7fqkKODt+Vt5vC/y6yhWHwBojTQdL6hevXOItIfHRg jy1/RgP66zf4FJ2ZFKjY3NXAYF+HcrA1uf/U30Uo2kI8uth4qadWTaqw/q/+H2kX6SZ7TKhJYNpX3 kYZ7I0VCEVKiP78p9+YgsIona0ht5iOghnVyBUWraEgmMgV99rv7RN/5AjyRBULijisqheNhgcOka zPft1/Ww==; Received: from [82.138.51.3] (port=61009 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kPlN3-0001Co-C6; Tue, 06 Oct 2020 07:43:05 -0400 From: "Valery Smyslov" To: Cc: , Date: Tue, 6 Oct 2020 14:43:04 +0300 Message-ID: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Adab1OgBrqjjS4NlQFeILndcywZANQ== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 06 Oct 2020 11:43:13 -0000 Hi, this message starts a two-week working group last call for draft-ietf-dots-rfc8782-bis-01, which will end on Wednesday, October 21. Please, review the draft carefully and send your comments to the mailing list. Regards, Frank & Valery. From nobody Tue Oct 6 05:02: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 C030B3A141D for ; Tue, 6 Oct 2020 05:01: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.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 o9ilgoVjHnew for ; Tue, 6 Oct 2020 05:01:57 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 2EEBD3A1331 for ; Tue, 6 Oct 2020 05:01:57 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id z8so1034578lfd.11 for ; Tue, 06 Oct 2020 05:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AaIJxLoa1sZUJAa25fnMzr8DBSjE5kDTEJ2raYQLntM=; b=dDKwFqsB4KhHp74zB/RnAjvd0MHnSh6sXTmbZrXOokqye3E96dAnUyuAeBBTKbnORO /bTWBBc/SUmFzzIIVW3OjEwZ5/yL4x/CgUNAJQl2v71GZMP/b6qQyOnEST5Y9/M6MlsV rlXxxXJA3P0TgRAH+MJAyHCR2p1ICUxdbEhBVMhrTZKQj3BVXyTaTJ/B/w96XJIXhGh1 no1vuc3CFP/oMtDvqek5/KF4Oqj1c212S7OaQDbLXv/uJWr7AhetJYHZmFTkYWaDAZNl LMx5XQudsFdJyYAybZs9yGWLRKIY681KKRvVf1ZN0i9obk0AkFZY3jq8PUFIKeZmrvO7 RyQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AaIJxLoa1sZUJAa25fnMzr8DBSjE5kDTEJ2raYQLntM=; b=N57oUXKwb4CN2PX0DnEazzavSflWCntVtGQm09nqizFO89+P1XD2LnBPIxghFrz5Xd RgyMyDa1bPngoUH20zPUbjJrgNC/55FwG+qkBSIzYDYNs85qRSKMPnNW/gwURDYG0KDL dZHBwuq9dWRdIOUalh7yUNGQQQVDFhzvBhIBwjZq1QV8cyS4bTETAJJF5eS1omajxj4G eFSNj196J9c0/YlZtZemycg1B8eB2w8rVU4HB4dy5xNNbrvnOcccXL4xvlRzYVjV7u/B 8PtLRtv1fEOYJddV2suR+2dWgIzixV1Xzui09x1SA/kDknsIgv0CDJ2Fp5HyExguAzzC MoiQ== X-Gm-Message-State: AOAM5317Yso/SzcOryUgYZ2xtKzUrwOc/vNa9qEcq2ZLCldyX6LmOvBU hk1hTJGQwDiw7o8zBHFKPsc9JTNn/vM3VcLo7izD1W089cLg/9GW X-Google-Smtp-Source: ABdhPJwk0mWq28DPXAqhutbYLpMN/9wvvLLTdZXtG7D2lp6QMJ8nMQoUSBM5EFh4FA3xze8jOOOH4rdLCgS6n28udwY= X-Received: by 2002:ac2:43a2:: with SMTP id t2mr412783lfl.421.1601985715043; Tue, 06 Oct 2020 05:01:55 -0700 (PDT) MIME-Version: 1.0 References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> In-Reply-To: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> From: Yasuaki Morita Date: Tue, 6 Oct 2020 12:01:44 +0000 Message-ID: To: Valery Smyslov Cc: dots@ietf.org, dots-chairs@ietf.org, draft-ietf-dots-rfc8782-bis@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 06 Oct 2020 12:01:59 -0000 Hi all, Let me point out two things about the draft. First, lifetime is defined to be an optional leaf on the Yang tree diagram. But lifetime is mandatory as other parts of the draft and I believe that `lifetime?` in the tree should be replaced by `lifetime`. Here is an excerpt from the tree-diagram: structure dots-signal: +-- (message-type)? +--:(mitigation-scope) | +-- scope* [] ...(snip)... | +-- lifetime? union >From the description of lifetime: lifetime: Lifetime of the mitigation request in seconds. ...(snip)... The DOTS server MUST always indicate the actual lifetime in the response and the remaining lifetime in status messages sent to the DOTS client. This is a mandatory attribute. Second, I guess that the attribute `:(client-to-server-only)` for attack-status in the tree diagram is redundant or confusing. I believe that the clients should be able to obtain its current attack-status from the server, but `:(client-to-server-only)` seems like forbidding it. There is no reason to restrict the server sending attack-status to the clients. So I suggest that we simply write | +-- attack-status? | iana-dots-signal:attack-status instead of | +--:(client-to-server-only) | +-- attack-status? | iana-dots-signal:attack-status Best regards Yasuaki On Tue, 6 Oct 2020 at 11:43, Valery Smyslov wrote: > > Hi, > > this message starts a two-week working group last call for draft-ietf-dots-rfc8782-bis-01, > which will end on Wednesday, October 21. Please, review the draft carefully and > send your comments to the mailing list. > > Regards, > Frank & Valery. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Oct 6 05:49: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 C3B5A3A1453; Tue, 6 Oct 2020 05:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smFxssFikK51; Tue, 6 Oct 2020 05:48:57 -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 01F953A1420; Tue, 6 Oct 2020 05:48:56 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4C5HMq4yKyzCrVd; Tue, 6 Oct 2020 14:48:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601988535; bh=14VUAfoeXAE/6R+3x5yNpJA4BKb5M7/ho023aE+2+zo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=EohqesNXr/iBc+86R7iKmXUZZyby2u6XBSL6Sfrj7Ep26GhktnmBmG5KUUXdez9a+ rPyXl4257dKhMRIYxEK33+KBcbR5CB2KTtAbfA056r2aF6aPbyB9umFk850po5lwrw ORKmEvDir91gESdNIU8zUgCWRXDLsCjAhwUCkhujpl218mk50sILyljqloKEn1/FEP kUHF3XYidpnOr+1Dovb0Apv7cN6EX4q9r6zIhv6TC8endO8GYocXkHi0RHw307exQe EH5lv2fRfrjJPaktFCoy6QmhLxI4d9VPJRbpm/mkLwscgZokbVnZPz/F0q2/Jf2EJi Q/eVjUpdFOBow== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4C5HMq3cQxz1y5B; Tue, 6 Oct 2020 14:48:55 +0200 (CEST) From: To: Yasuaki Morita , Valery Smyslov CC: "dots@ietf.org" , "dots-chairs@ietf.org" , "draft-ietf-dots-rfc8782-bis@ietf.org" Thread-Topic: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 Thread-Index: AQHWm9iARdqc/jnVQUaJq+rs9dLPiKmKgdjQ Date: Tue, 6 Oct 2020 12:48:54 +0000 Message-ID: <14948_1601988535_5F7C67B7_14948_426_3_787AE7BB302AE849A7480A190F8B93303154DCDC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> 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] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 06 Oct 2020 12:48:59 -0000 SGkgWWFzdWFraSwgDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLiANCg0KUGxlYXNlIHNl ZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gRGXCoDogWWFzdWFraSBNb3JpdGEgW21haWx0bzp5YXN1YWtpLm1vcml0YUBsZXBpZHVt LmNvLmpwXQ0KPiBFbnZvecOpwqA6IG1hcmRpIDYgb2N0b2JyZSAyMDIwIDE0OjAyDQo+IMOAwqA6 IFZhbGVyeSBTbXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+DQo+IENjwqA6IGRvdHNAaWV0Zi5v cmc7IGRvdHMtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLWRvdHMtcmZjODc4Mi0NCj4gYmlz QGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbRG90c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1kb3Rz LXJmYzg3ODItYmlzLTAxDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBMZXQgbWUgcG9pbnQgb3V0IHR3 byB0aGluZ3MgYWJvdXQgdGhlIGRyYWZ0Lg0KPiANCj4gRmlyc3QsIGxpZmV0aW1lIGlzIGRlZmlu ZWQgdG8gYmUgYW4gb3B0aW9uYWwgbGVhZiBvbiB0aGUgWWFuZyB0cmVlDQo+IGRpYWdyYW0uDQoN CltNZWRdIEkgY29uZmlybS4NCg0KPiBCdXQgbGlmZXRpbWUgaXMgbWFuZGF0b3J5IGFzIG90aGVy IHBhcnRzIG9mIHRoZSBkcmFmdA0KDQpbTWVkXSBJdCBpcyBtYW5kYXRvcnkgaW4gYSByZXF1ZXN0 IGFuZCBhbiBhY2NlcHRlZCBtaXRpZ2F0aW9uIHJlc3BvbnNlLCBidXQgbm90IGluIGEgY29uZmxp Y3QgcmVzcG9uc2UgZm9yIGluc3RhbmNlLg0KDQpUaGUgc3RydWN0dXJlIGFwcGxpZXMgb2YgdGhl IG1pdGlnYXRpb24gaW5kZXBlbmRlbnRseSB3aGV0aGVyIHRoaXMgYSByZXF1ZXN0LCByZXNwb25z ZSwgY29uZmxpY3QsIGVmZmljYWN5IHVwZGF0ZSwgZXRjLiAgDQoNCiBhbmQgSSBiZWxpZXZlDQo+ IHRoYXQgYGxpZmV0aW1lP2AgaW4gdGhlIHRyZWUgc2hvdWxkIGJlIHJlcGxhY2VkIGJ5IGBsaWZl dGltZWAuDQo+IA0KPiBIZXJlIGlzIGFuIGV4Y2VycHQgZnJvbSB0aGUgdHJlZS1kaWFncmFtOg0K PiANCj4gDQo+ICAgICAgIHN0cnVjdHVyZSBkb3RzLXNpZ25hbDoNCj4gICAgICAgICArLS0gKG1l c3NhZ2UtdHlwZSk/DQo+ICAgICAgICAgICAgKy0tOihtaXRpZ2F0aW9uLXNjb3BlKQ0KPiAgICAg ICAgICAgIHwgICstLSBzY29wZSogW10NCj4gICAgICAgICAgICAuLi4oc25pcCkuLi4NCj4gICAg ICAgICAgICB8ICAgICArLS0gbGlmZXRpbWU/ICAgICAgICAgICAgICAgICAgICAgdW5pb24NCj4g DQo+IA0KPiA+RnJvbSB0aGUgZGVzY3JpcHRpb24gb2YgbGlmZXRpbWU6DQo+IA0KPiAgICBsaWZl dGltZTogIExpZmV0aW1lIG9mIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgaW4gc2Vjb25kcy4NCj4g ICAgICAgLi4uKHNuaXApLi4uDQo+ICAgICAgIFRoZSBET1RTIHNlcnZlciBNVVNUIGFsd2F5cyBp bmRpY2F0ZSB0aGUgYWN0dWFsIGxpZmV0aW1lIGluDQo+IHRoZQ0KPiAgICAgICByZXNwb25zZSBh bmQgdGhlIHJlbWFpbmluZyBsaWZldGltZSBpbiBzdGF0dXMgbWVzc2FnZXMgc2VudCB0bw0KPiB0 aGUNCj4gICAgICAgRE9UUyBjbGllbnQuDQo+ICAgICAgIFRoaXMgaXMgYSBtYW5kYXRvcnkgYXR0 cmlidXRlLg0KPiANCj4gDQo+IFNlY29uZCwgSSBndWVzcyB0aGF0IHRoZSBhdHRyaWJ1dGUgYDoo Y2xpZW50LXRvLXNlcnZlci1vbmx5KWAgZm9yDQo+IGF0dGFjay1zdGF0dXMgaW4gdGhlIHRyZWUg ZGlhZ3JhbSBpcyByZWR1bmRhbnQgb3IgY29uZnVzaW5nLg0KPiBJIGJlbGlldmUgdGhhdCB0aGUg Y2xpZW50cyBzaG91bGQgYmUgYWJsZSB0byBvYnRhaW4gaXRzIGN1cnJlbnQNCj4gYXR0YWNrLXN0 YXR1cyBmcm9tIHRoZSBzZXJ2ZXIsIGJ1dCBgOihjbGllbnQtdG8tc2VydmVyLW9ubHkpYCBzZWVt cw0KPiBsaWtlIGZvcmJpZGRpbmcgaXQuDQoNCltNZWRdICJhdHRhY2stc3RhdHVzIiBpcyBhbiBh dHRyaWJ1dGUgdGhhdCBpcyBzZW50IGJ5IGEgY2xpZW50IHRvIHNoYXJlIGl0cyB2aWV3IG9uIHRo ZSBhdHRhY2sgd2l0aCB0aGUgc2VydmVyLiBUaGUgc2VydmVyIG1hbmlwdWxhdGVzICJzdGF0dXMi IHRvIHJlcG9ydCB0aGUgc3RhdHVzIGFzIHNlZW4gYXQgdGhlIHNlcnZlciBzaWRlLiANCg0KVGhl IHNlcnZlciBkb2VzIG5vdCBpbmNsdWRlIHRoZSAiYXR0YWNrLXN0YXR1cyIgKHJlY2VpdmVkIGZy b20gdGhlIGNsaWVudCkgaW4gYSBHRVQuDQoNCj4gVGhlcmUgaXMgbm8gcmVhc29uIHRvIHJlc3Ry aWN0IHRoZSBzZXJ2ZXIgc2VuZGluZyBhdHRhY2stc3RhdHVzIHRvDQo+IHRoZSBjbGllbnRzLg0K DQpbTWVkXSBXaGF0IHdvdWxkIGJlIHRoZSB1c2UgY2FzZSBpZiB0aGF0IGNvbnN0cmFpbnQgd2Fz IHJlbGF4ZWQ/DQoNCg0KPiBTbyBJIHN1Z2dlc3QgdGhhdCB3ZSBzaW1wbHkgd3JpdGUNCj4gDQo+ ICAgICAgICAgICAgfCAgICAgICAgKy0tIGF0dGFjay1zdGF0dXM/DQo+ICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICBpYW5hLWRvdHMtc2lnbmFsOmF0dGFjay1zdGF0dXMNCj4gDQo+IGluc3Rl YWQgb2YNCj4gDQo+ICAgICAgICAgICAgfCAgICAgICAgKy0tOihjbGllbnQtdG8tc2VydmVyLW9u bHkpDQo+ICAgICAgICAgICAgfCAgICAgICAgICAgKy0tIGF0dGFjay1zdGF0dXM/DQo+ICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICBpYW5hLWRvdHMtc2lnbmFsOmF0dGFjay1zdGF0dXMN Cj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMNCj4gWWFzdWFraQ0KPiANCj4gDQo+IE9uIFR1ZSwgNiBP Y3QgMjAyMCBhdCAxMTo0MywgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD4NCj4g d3JvdGU6DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IHRoaXMgbWVzc2FnZSBzdGFydHMgYSB0d28t d2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3INCj4gPiBkcmFmdC1pZXRmLWRvdHMtcmZj ODc4Mi1iaXMtMDEsIHdoaWNoIHdpbGwgZW5kIG9uIFdlZG5lc2RheSwNCj4gT2N0b2Jlcg0KPiA+ IDIxLiBQbGVhc2UsIHJldmlldyB0aGUgZHJhZnQgY2FyZWZ1bGx5IGFuZCBzZW5kIHlvdXIgY29t bWVudHMgdG8NCj4gdGhlIG1haWxpbmcgbGlzdC4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gRnJh bmsgJiBWYWxlcnkuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gRG90c0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4K VGhhbmsgeW91LgoK From nobody Tue Oct 6 07:58: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 206CD3A0AB6 for ; Tue, 6 Oct 2020 07:58:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.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-JhP_E86crR for ; Tue, 6 Oct 2020 07:58:35 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D0A3A0AB7 for ; Tue, 6 Oct 2020 07:58:34 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id w11so15412267lfn.2 for ; Tue, 06 Oct 2020 07:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pAGie7VS0dzBIKKi0krhi3HbHt8GrJacsMrbLc7Qg64=; b=mCcA8D9YG6P15kTZM2kkB1+xmOQwm9zrsavZpEBJFqU4j6gkroGHVf7jkrOJNyf3BX h1UJErg2T/c+dtJ2pLZ98IdypZ6poNem6Wlu2P81KoF4CXXZj+v+thuUOjEsPYrfBq1X XQ5ugRfXMRK+ZYTOvshmAGsn49Aq0E2+1y/lbmclYpsjfyFKngnROh4E5CHfArf9I+t4 /oJMAkl6YF3cWQkSLlcwkrCyLp0j9zFHnn8HSIlSpTLK00kNXNT1vmqU3XGtehrCMHPp q9oB24unICbzjsfNCXuFT3xfbY8pRDVO4gAnJkj0DzAIGyH0J3Qf0fx4YbeaWIn3NtTT cA3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pAGie7VS0dzBIKKi0krhi3HbHt8GrJacsMrbLc7Qg64=; b=pDXoGmje2BYq9sgthybuQuM5AF2Um6Jqv7DBBJz60IUKqSd5Eq/DWNGEbRh3txjXUq fop8dHYKaIxsMnFut2mzzXbHK5F1R1TBDZBXCQFs8uWrgbKuiHh4Jtnb2VDNjH8yWcXj whFqLU9VShGqG2oE1jUN5vQBYP3YjeH2oN/BUNouxnphmOxK080+bWZbj9tolCOX7oUg auqKhJQ127zhjFQlKM2sK1KB6qPVG6Tk09VbitVTUzH+Q3pzJxYgMbosPLqCp+kkbih5 lfHEO1Lzt9PaB6K0CJX1Ub3bGzdHaOywztuWdmJYBL/s/PNccuLtU1ERPwW1Wg2zHZSU M5GQ== X-Gm-Message-State: AOAM530fWDw1Ij3RwP/oiesaO1LIQNIttnJasttK1gAeoMRrV7LOWwxr bQfnjvKrSPyHYVXUiTdbJf0mR7jLKS0Wte+Fx4FFLg== X-Google-Smtp-Source: ABdhPJwNIY6fijMoGKekjmxyWjXElPF62Pprwfbmnc3p21NxbvNVW9qUMir8dwjIVwlO2wAuwzf1UVfTGXNeLsjOzWg= X-Received: by 2002:a19:e305:: with SMTP id a5mr612292lfh.549.1601996312899; Tue, 06 Oct 2020 07:58:32 -0700 (PDT) MIME-Version: 1.0 References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> <14948_1601988535_5F7C67B7_14948_426_3_787AE7BB302AE849A7480A190F8B93303154DCDC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <14948_1601988535_5F7C67B7_14948_426_3_787AE7BB302AE849A7480A190F8B93303154DCDC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yasuaki Morita Date: Tue, 6 Oct 2020 14:58:22 +0000 Message-ID: To: mohamed.boucadair@orange.com Cc: Valery Smyslov , "dots@ietf.org" , "dots-chairs@ietf.org" , "draft-ietf-dots-rfc8782-bis@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 06 Oct 2020 14:58:37 -0000 Hi Med Thank you for your reply. > [Med] It is mandatory in a request and an accepted mitigation response, b= ut not in a conflict response for instance. > The structure applies of the mitigation independently whether this a requ= est, response, conflict, efficacy update, etc. I see, I understand. > [Med] "attack-status" is an attribute that is sent by a client to share i= ts view on the attack with the server. The server manipulates "status" to r= eport the status as seen at the server side. > The server does not include the "attack-status" (received from the client= ) in a GET. > > > There is no reason to restrict the server sending attack-status to > > the clients. Perhaps this is something I didn't understand correctly about the use of "attack-status" in RFC8782 (not bis), which defines "attack-status" as the following. | +--rw attack-status? iana-signal:attack-status > > [Med] What would be the use case if that constraint was relaxed? I can explain the use case but I am not sure it is meaningful. Let a client send a PUT mitigation request to the server, and another client program send a GET request to obtain that mitigation request. In this case, the latter client might get more information if the GET response includes attack-status. On Tue, 6 Oct 2020 at 12:48, wrote: > > Hi Yasuaki, > > Thank you for the comments. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Yasuaki Morita [mailto:yasuaki.morita@lepidum.co.jp] > > Envoy=C3=A9 : mardi 6 octobre 2020 14:02 > > =C3=80 : Valery Smyslov > > Cc : dots@ietf.org; dots-chairs@ietf.org; draft-ietf-dots-rfc8782- > > bis@ietf.org > > Objet : Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 > > > > Hi all, > > > > Let me point out two things about the draft. > > > > First, lifetime is defined to be an optional leaf on the Yang tree > > diagram. > > [Med] I confirm. > > > But lifetime is mandatory as other parts of the draft > > [Med] It is mandatory in a request and an accepted mitigation response, b= ut not in a conflict response for instance. > > The structure applies of the mitigation independently whether this a requ= est, response, conflict, efficacy update, etc. > > and I believe > > that `lifetime?` in the tree should be replaced by `lifetime`. > > > > Here is an excerpt from the tree-diagram: > > > > > > structure dots-signal: > > +-- (message-type)? > > +--:(mitigation-scope) > > | +-- scope* [] > > ...(snip)... > > | +-- lifetime? union > > > > > > >From the description of lifetime: > > > > lifetime: Lifetime of the mitigation request in seconds. > > ...(snip)... > > The DOTS server MUST always indicate the actual lifetime in > > the > > response and the remaining lifetime in status messages sent to > > the > > DOTS client. > > This is a mandatory attribute. > > > > > > Second, I guess that the attribute `:(client-to-server-only)` for > > attack-status in the tree diagram is redundant or confusing. > > I believe that the clients should be able to obtain its current > > attack-status from the server, but `:(client-to-server-only)` seems > > like forbidding it. > > [Med] "attack-status" is an attribute that is sent by a client to share i= ts view on the attack with the server. The server manipulates "status" to r= eport the status as seen at the server side. > > The server does not include the "attack-status" (received from the client= ) in a GET. > > > There is no reason to restrict the server sending attack-status to > > the clients. > > [Med] What would be the use case if that constraint was relaxed? > > > > So I suggest that we simply write > > > > | +-- attack-status? > > | iana-dots-signal:attack-status > > > > instead of > > > > | +--:(client-to-server-only) > > | +-- attack-status? > > | iana-dots-signal:attack-status > > > > > > Best regards > > Yasuaki > > > > > > On Tue, 6 Oct 2020 at 11:43, Valery Smyslov > > wrote: > > > > > > Hi, > > > > > > this message starts a two-week working group last call for > > > draft-ietf-dots-rfc8782-bis-01, which will end on Wednesday, > > October > > > 21. Please, review the draft carefully and send your comments to > > the mailing list. > > > > > > Regards, > > > Frank & Valery. > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > From nobody Tue Oct 6 23: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 D09723A1650; Tue, 6 Oct 2020 23:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZosljLn-7TV; Tue, 6 Oct 2020 23:24:04 -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 1BC153A1170; Tue, 6 Oct 2020 23:24:04 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4C5knG3FFPz5x9h; Wed, 7 Oct 2020 08:24:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602051842; bh=ZzZq9TL5zLiby3xazVQ/ZbXQgqNdxxTCfcGU0pCoTUI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hKJJAYMjj51zuhEi2x5afoyxnRKKZTWG/pnt9T5YN4h20RXXuQ/yXiGzFup3bfuEn CIuF57xDg/ZV7QRiFqzXYFfep7OP71FDNlaSo2oSZXBHa3uTo9K/fs8W1o3HdJ7573 FLegtSM8EIxFL0fZol7MElNriaxQ30ZCk+62LISwZimdYQjJzdCYgLDWTXu6IBr1LL VCXH29HrUfelMFagL3zdVS647biHLebRKJtp1foDD/EYSfZp3rp2NtUuzzD80aWH1x Owfaz1v/QOJtnl3du6GfWpTpLiK0esemcgsUlQkD52EjAoWTQ5Z+VXdWfJVPYjqWLQ zOXfWUfSCzaLQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4C5knG1tMfzCqkC; Wed, 7 Oct 2020 08:24:02 +0200 (CEST) From: To: Yasuaki Morita CC: Valery Smyslov , "dots@ietf.org" , "dots-chairs@ietf.org" , "draft-ietf-dots-rfc8782-bis@ietf.org" Thread-Topic: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 Thread-Index: AQHWm/Eq/T+7BVNhfkehy5Yxe/q6zKmLqUxg Date: Wed, 7 Oct 2020 06:24:01 +0000 Message-ID: <17820_1602051842_5F7D5F02_17820_303_1_787AE7BB302AE849A7480A190F8B93303154E25F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> <14948_1601988535_5F7C67B7_14948_426_3_787AE7BB302AE849A7480A190F8B93303154DCDC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 07 Oct 2020 06:24:06 -0000 SGkgWWFzdWFraSwgDQoNClRoYW5rIHlvdSBmb3IgY2xhcmlmeWluZy4gDQoNCj4gSSBjYW4gZXhw bGFpbiB0aGUgdXNlIGNhc2UgYnV0IEkgYW0gbm90IHN1cmUgaXQgaXMgbWVhbmluZ2Z1bC4NCj4g TGV0IGEgY2xpZW50IHNlbmQgYSBQVVQgbWl0aWdhdGlvbiByZXF1ZXN0IHRvIHRoZSBzZXJ2ZXIs IGFuZA0KPiBhbm90aGVyIGNsaWVudCBwcm9ncmFtIHNlbmQgYSBHRVQgcmVxdWVzdCB0byBvYnRh aW4gdGhhdCBtaXRpZ2F0aW9uDQo+IHJlcXVlc3QuDQo+IEluIHRoaXMgY2FzZSwgdGhlIGxhdHRl ciBjbGllbnQgbWlnaHQgZ2V0IG1vcmUgaW5mb3JtYXRpb24gaWYgdGhlDQo+IEdFVCByZXNwb25z ZSBpbmNsdWRlcyBhdHRhY2stc3RhdHVzLg0KDQooUHV0dGluZyBhc2lkZSBob3cgdGhlIGluZm9y bWF0aW9uIHdpbGwgYmUgdXNlZCBieSB0aGUgc2Vjb25kIGNsaWVudDogYW5vbWFseSBkZXRlY3Qg YW1vbmcgY2xpZW50cyBvZiB0aGUgc2FtZSBkb21haW4oPykpDQoNClRoaXMgYXNzdW1lcyB0aGF0 IHRoZSBzZXJ2ZXIgbWFpbnRhaW5zIHR3byBtaXRpZ2F0aW9uIHJlcXVlc3RzIHdpdGggY29uZmxp Y3Rpbmcgc2NvcGVzIGFuZCB3aGljaCBhcmUgaXNzdWVkIGJ5IGRpc3RpbmN0IGNsaWVudHMgb2Yg dGhlIHNhbWUgZG9tYWluLiBUaGlzIGlzIG5vdCBhbGxvd2VkIGluIHRoZSBjdXJyZW50IHNwZWMu IFdoZW4gc3VjaCBtaXRpZ2F0aW9ucyBhcmUgcmVjZWl2ZWQsIGlzIGxpa2VseSB0byBtYWludGFp biBvbmx5IG9uZSBvZiB0aGVtIGFjdGl2ZS4gDQoNClNvIGV2ZW4gaWYgdGhlIGNvbnN0cmFpbnQg aXMgcmVsYXhlZCB0byBlY2hvICJhdHRhY2stc3RhdHVzIiBieSBhIHNlcnZlciwgb25seSB0aGUg Y2xpZW50IHRoYXQgY29tbXVuaWNhdGVkIHRoZSBwYXJhbWV0ZXIgY2FuIGFjY2VzcyBpdCAuLi4g YnV0IEkgZG9uJ3Qgc2VlIHdoeSB3ZSBuZWVkIHRvIGRvIHRoYXQuICANCg0KQ2hlZXJzLA0KTWVk DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFlhc3Vha2kgTW9yaXRh IFttYWlsdG86eWFzdWFraS5tb3JpdGFAbGVwaWR1bS5jby5qcF0NCj4gRW52b3nDqcKgOiBtYXJk aSA2IG9jdG9icmUgMjAyMCAxNjo1OA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xO IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBDY8KgOiBWYWxlcnkgU215c2xvdiA8 dmFsZXJ5QHNteXNsb3YubmV0PjsgZG90c0BpZXRmLm9yZzsgZG90cy0NCj4gY2hhaXJzQGlldGYu b3JnOyBkcmFmdC1pZXRmLWRvdHMtcmZjODc4Mi1iaXNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6 IFtEb3RzXSBXR0xDIGZvciBkcmFmdC1pZXRmLWRvdHMtcmZjODc4Mi1iaXMtMDENCj4gDQo+IEhp IE1lZA0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPiANCj4gPiBbTWVkXSBJdCBp cyBtYW5kYXRvcnkgaW4gYSByZXF1ZXN0IGFuZCBhbiBhY2NlcHRlZCBtaXRpZ2F0aW9uDQo+IHJl c3BvbnNlLCBidXQgbm90IGluIGEgY29uZmxpY3QgcmVzcG9uc2UgZm9yIGluc3RhbmNlLg0KPiA+ IFRoZSBzdHJ1Y3R1cmUgYXBwbGllcyBvZiB0aGUgbWl0aWdhdGlvbiBpbmRlcGVuZGVudGx5IHdo ZXRoZXIgdGhpcw0KPiBhIHJlcXVlc3QsIHJlc3BvbnNlLCBjb25mbGljdCwgZWZmaWNhY3kgdXBk YXRlLCBldGMuDQo+IA0KPiBJIHNlZSwgSSB1bmRlcnN0YW5kLg0KPiANCj4gPiBbTWVkXSAiYXR0 YWNrLXN0YXR1cyIgaXMgYW4gYXR0cmlidXRlIHRoYXQgaXMgc2VudCBieSBhIGNsaWVudCB0bw0K PiBzaGFyZSBpdHMgdmlldyBvbiB0aGUgYXR0YWNrIHdpdGggdGhlIHNlcnZlci4gVGhlIHNlcnZl ciBtYW5pcHVsYXRlcw0KPiAic3RhdHVzIiB0byByZXBvcnQgdGhlIHN0YXR1cyBhcyBzZWVuIGF0 IHRoZSBzZXJ2ZXIgc2lkZS4NCj4gPiBUaGUgc2VydmVyIGRvZXMgbm90IGluY2x1ZGUgdGhlICJh dHRhY2stc3RhdHVzIiAocmVjZWl2ZWQgZnJvbSB0aGUNCj4gY2xpZW50KSBpbiBhIEdFVC4NCj4g Pg0KPiA+ID4gVGhlcmUgaXMgbm8gcmVhc29uIHRvIHJlc3RyaWN0IHRoZSBzZXJ2ZXIgc2VuZGlu ZyBhdHRhY2stc3RhdHVzDQo+IHRvDQo+ID4gPiB0aGUgY2xpZW50cy4NCj4gDQo+IFBlcmhhcHMg dGhpcyBpcyBzb21ldGhpbmcgSSBkaWRuJ3QgdW5kZXJzdGFuZCBjb3JyZWN0bHkgYWJvdXQgdGhl DQo+IHVzZSBvZiAiYXR0YWNrLXN0YXR1cyIgaW4gUkZDODc4MiAobm90IGJpcyksIHdoaWNoIGRl ZmluZXMgImF0dGFjay0NCj4gc3RhdHVzIg0KPiBhcyB0aGUgZm9sbG93aW5nLg0KPiANCj4gICAg ICAgICAgICB8ICAgICArLS1ydyBhdHRhY2stc3RhdHVzPyAgICAgICAgICBpYW5hLXNpZ25hbDph dHRhY2stDQo+IHN0YXR1cw0KPiANCj4gPg0KPiA+IFtNZWRdIFdoYXQgd291bGQgYmUgdGhlIHVz ZSBjYXNlIGlmIHRoYXQgY29uc3RyYWludCB3YXMgcmVsYXhlZD8NCj4gDQo+IEkgY2FuIGV4cGxh aW4gdGhlIHVzZSBjYXNlIGJ1dCBJIGFtIG5vdCBzdXJlIGl0IGlzIG1lYW5pbmdmdWwuDQo+IExl dCBhIGNsaWVudCBzZW5kIGEgUFVUIG1pdGlnYXRpb24gcmVxdWVzdCB0byB0aGUgc2VydmVyLCBh bmQNCj4gYW5vdGhlciBjbGllbnQgcHJvZ3JhbSBzZW5kIGEgR0VUIHJlcXVlc3QgdG8gb2J0YWlu IHRoYXQgbWl0aWdhdGlvbg0KPiByZXF1ZXN0Lg0KPiBJbiB0aGlzIGNhc2UsIHRoZSBsYXR0ZXIg Y2xpZW50IG1pZ2h0IGdldCBtb3JlIGluZm9ybWF0aW9uIGlmIHRoZQ0KPiBHRVQgcmVzcG9uc2Ug aW5jbHVkZXMgYXR0YWNrLXN0YXR1cy4NCj4gDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Oct 7 04:49: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 CAD243A0A7D for ; Wed, 7 Oct 2020 04:49:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.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 yAml-9ZqJlcA for ; Wed, 7 Oct 2020 04:49:47 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642123A0A80 for ; Wed, 7 Oct 2020 04:49:43 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id b22so1893804lfs.13 for ; Wed, 07 Oct 2020 04:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wCEI/Xnmt2pGliGAmYGMfiNn1qLPkB6BoM0dwq+UHKo=; b=dBDbGXvksufqdkQX9WlKFjCMJWLnEYdQTYQ5m///aJ5z5NaOqxpb+mnvclbaK1TkbY kXtc3QC2UfMuqpD1WhUVt6f08qWcAvvE0hGjXDVoBSHvOzmMWJOuB2aPoRQcB81fHuJ9 vUdAuqqYGrIvUU5Dh5TEP5/F5vLjvDp/32YXNxh7RccTZV6pMQd6YizIAneLD6zkd98A VYjY+fWH4E1bE1AfULuVpJsvXh3pn6qj3F+5BupO+c+led81aHpMpH5/MbG08fQxMWRn r/5dSl4W2uqAcq1epHG8Co/uxHQhN5iwioUoXmWcmZkDqGUaFCJF+LuSyZdRm/kKQnSE 5KIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wCEI/Xnmt2pGliGAmYGMfiNn1qLPkB6BoM0dwq+UHKo=; b=BLZrsJFGIEkwoH3OffG2v3zXwiFA8ydDWQ5EUN+4/S4+yHINjdt4l2VBh7Ch9NbaTx CwoAsxWBrMDyELeFG6BkxvkTCUT7nuFvKSKoyMi4zNCWN2awpCeH9hIdbQX8n9mDwJcO 3UDKKAzryNj67sZ7n+uYT9dICn3ATU+2EZd7pl4Gy8+LOVx7NrQbH9PFIxZA1FpZl3DW aPpqPIEUXdaVYA68oh71YLvc1MC4J5KklaMVFQje8AXPM2i1T7D5OkNmdxNAfJUQYddf Rpul67s6YZmR8Es7JWhNdRvGDmfHk57LtaR7yRRE6F+AMDf2FToaM2yS44tuK04513y7 loGA== X-Gm-Message-State: AOAM533Fw+vYhXd774/xT37bFgFJD7JSVKHSIHf053t6NrlRZO7eVuYB +OTnQkF5b98Yt7XXDkyEdiAug7aw03u20gO9ROsf4w== X-Google-Smtp-Source: ABdhPJyZ5fOV7+y7+d+7Q+z6WASZbloBpBad7+9Kd3Yn0xZshOZq0cNSWMbs5nQYbKeecPOMMpJRiZ/+3BZa6cOo2ws= X-Received: by 2002:a19:771d:: with SMTP id s29mr752619lfc.521.1602071381203; Wed, 07 Oct 2020 04:49:41 -0700 (PDT) MIME-Version: 1.0 References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> <14948_1601988535_5F7C67B7_14948_426_3_787AE7BB302AE849A7480A190F8B93303154DCDC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <17820_1602051842_5F7D5F02_17820_303_1_787AE7BB302AE849A7480A190F8B93303154E25F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <17820_1602051842_5F7D5F02_17820_303_1_787AE7BB302AE849A7480A190F8B93303154E25F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yasuaki Morita Date: Wed, 7 Oct 2020 11:49:30 +0000 Message-ID: To: mohamed.boucadair@orange.com Cc: Valery Smyslov , "dots@ietf.org" , "dots-chairs@ietf.org" , "draft-ietf-dots-rfc8782-bis@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 07 Oct 2020 11:49:50 -0000 Hi, > (Putting aside how the information will be used by the second client: ano= maly detect among clients of the same domain(?)) > This assumes that the server maintains two mitigation requests with confl= icting scopes and which are issued by distinct clients of the same domain. = This is not allowed in the current spec. When such mitigations are received= , is likely to maintain only one of them active. > So even if the constraint is relaxed to echo "attack-status" by a server,= only the client that communicated the parameter can access it ... but I do= n't see why we need to do that. I assumed that multiple entities share and use cuid, once it is created. Say, when one of the entities creates cuid and PUT mitigation, and distributes its cuid and mid to the rest of them, so that they can request GET and check the status (or attack-status), it makes a bit of a difference regarding the presence of "attack-status" in GET responses. But now I understand the original use of attack-status. I think it has been clarified in bis better than the original RFC8782. Any doubts about ":(client-to-server)" have been resolved. Thank you. On Wed, 7 Oct 2020 at 06:24, wrote: > > Hi Yasuaki, > > Thank you for clarifying. > > > I can explain the use case but I am not sure it is meaningful. > > Let a client send a PUT mitigation request to the server, and > > another client program send a GET request to obtain that mitigation > > request. > > In this case, the latter client might get more information if the > > GET response includes attack-status. > > (Putting aside how the information will be used by the second client: ano= maly detect among clients of the same domain(?)) > > This assumes that the server maintains two mitigation requests with confl= icting scopes and which are issued by distinct clients of the same domain. = This is not allowed in the current spec. When such mitigations are received= , is likely to maintain only one of them active. > > So even if the constraint is relaxed to echo "attack-status" by a server,= only the client that communicated the parameter can access it ... but I do= n't see why we need to do that. > > Cheers, > Med > > > -----Message d'origine----- > > De : Yasuaki Morita [mailto:yasuaki.morita@lepidum.co.jp] > > Envoy=C3=A9 : mardi 6 octobre 2020 16:58 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > Cc : Valery Smyslov ; dots@ietf.org; dots- > > chairs@ietf.org; draft-ietf-dots-rfc8782-bis@ietf.org > > Objet : Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 > > > > Hi Med > > > > Thank you for your reply. > > > > > [Med] It is mandatory in a request and an accepted mitigation > > response, but not in a conflict response for instance. > > > The structure applies of the mitigation independently whether this > > a request, response, conflict, efficacy update, etc. > > > > I see, I understand. > > > > > [Med] "attack-status" is an attribute that is sent by a client to > > share its view on the attack with the server. The server manipulates > > "status" to report the status as seen at the server side. > > > The server does not include the "attack-status" (received from the > > client) in a GET. > > > > > > > There is no reason to restrict the server sending attack-status > > to > > > > the clients. > > > > Perhaps this is something I didn't understand correctly about the > > use of "attack-status" in RFC8782 (not bis), which defines "attack- > > status" > > as the following. > > > > | +--rw attack-status? iana-signal:attack- > > status > > > > > > > > [Med] What would be the use case if that constraint was relaxed? > > > > I can explain the use case but I am not sure it is meaningful. > > Let a client send a PUT mitigation request to the server, and > > another client program send a GET request to obtain that mitigation > > request. > > In this case, the latter client might get more information if the > > GET response includes attack-status. > > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > From nobody Thu Oct 8 06:53:48 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 0C7453A082F; Thu, 8 Oct 2020 06:53:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160216522698.30206.2821766755239604133@ietfa.amsl.com> Date: Thu, 08 Oct 2020 06:53:47 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-13.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 13:53:48 -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 Jon Shallow Filename : draft-ietf-dots-telemetry-13.txt Pages : 107 Date : 2020-10-08 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal Distributed Denial-of- Service 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 8 07:00: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 F1CA63A0997 for ; Thu, 8 Oct 2020 07:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eKvFVsuwTta for ; Thu, 8 Oct 2020 07:00:06 -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 E7B143A084A for ; Thu, 8 Oct 2020 07:00:05 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4C6Xs03gfKz5wQx for ; Thu, 8 Oct 2020 16:00:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602165604; bh=Jry0TcrBZQGdeij0TWWsLaOH2YozYv3g9o01srvIhu8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=dOyBH0XEmwyxi6EcrX9oULMmRsSCA5QKbWzWVNPnAxGEwgLa6Qvy5pv4hyGU5bU2C GF5+yAGvHtj2Tixt5xjxd9h82fOJjRafrmU6X2z+Muk4A4MyfC7sh5nJMAFWW19mE0 OynLm0+6oaZVem+muuDVBwJN1Mawv4fge90OV5rdxB/zPmw/wDWaJ7kDDa/AO4XQu8 zQ0P+W8u8NAUJwaJnOiYNzgq2iiR/1fZBiQ3zqhlBDcK3081XcFD1I0J2S4qbLIjzC Aaiun9jPE0YB2yYT0eRmwmrJtYUKRvwqCUYu8gZQ9luBe/aQgN5mAyFrwthEbGGi2Q NB/2Td8s/oHoA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4C6Xs02ps9z1xnY for ; Thu, 8 Oct 2020 16:00:04 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-13.txt Thread-Index: AQHWnXp2CkfV0w7oC02/ul/IPXt2dKmNuieQ Date: Thu, 8 Oct 2020 14:00:03 +0000 Message-ID: <10422_1602165604_5F7F1B64_10422_215_1_787AE7BB302AE849A7480A190F8B93303155A3C8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160216522698.30206.2821766755239604133@ietfa.amsl.com> In-Reply-To: <160216522698.30206.2821766755239604133@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-13.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, 08 Oct 2020 14:00:08 -0000 Hi all,=20 We made a minor edit to use the new Block3/4 names as defined by the core W= G: Quick-Block1/2.=20 We also fixed a very minor error in the YANG module.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 8 octobre 2020 15:54 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-telemetry-13.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 > Jon Shallow > Filename : draft-ietf-dots-telemetry-13.txt > Pages : 107 > Date : 2020-10-08 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal Distributed Denial- > of- > Service 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-13 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-13 >=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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Oct 9 02:40: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 56B393A0E18 for ; Fri, 9 Oct 2020 02:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FONT_INVIS_MSGID=0.001, 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 rPRS9BzqV4jl for ; Fri, 9 Oct 2020 02:39:58 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9DB3A0E17 for ; Fri, 9 Oct 2020 02:39:56 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app04-12004 (RichMail) with SMTP id 2ee45f802fd96fc-91da1; Fri, 09 Oct 2020 17:39:37 +0800 (CST) X-RM-TRANSID: 2ee45f802fd96fc-91da1 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[10.2.49.187]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5f802fd7ad3-79ce0; Fri, 09 Oct 2020 17:39:37 +0800 (CST) X-RM-TRANSID: 2eea5f802fd7ad3-79ce0 Date: Fri, 9 Oct 2020 17:39:53 +0800 From: "Meiling Chen" To: mohamed.boucadair , dots References: <160216522698.30206.2821766755239604133@ietfa.amsl.com>, <10422_1602165604_5F7F1B64_10422_215_1_787AE7BB302AE849A7480A190F8B93303155A3C8@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: <2020100917395360828419@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart260306307088_=----" Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-13.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, 09 Oct 2020 09:40:00 -0000 This is a multi-part message in MIME format. ------=_001_NextPart260306307088_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgbWVkLA0KSXMgUXVpY2stQmxvY2sgc3BlY2lmaWMgdG8gVGVsZW1ldHJ5IHRyYW5zZmVyIG9y IGdlbmVyYWwgdG8gU2lnbmFsIHB1dCBtZXRob2Q/DQoNCkJlc3QgUmVnYXJkcywNCk1laWxpbmcN Cg0KRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KRGF0ZTogMjAyMC0xMC0wOCAy MjowMA0KVG86IGRvdHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRG90c10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS0xMy50eHQNCkhpIGFsbCwgDQogDQpXZSBtYWRlIGEg bWlub3IgZWRpdCB0byB1c2UgdGhlIG5ldyBCbG9jazMvNCBuYW1lcyBhcyBkZWZpbmVkIGJ5IHRo ZSBjb3JlIFdHOiBRdWljay1CbG9jazEvMi4gDQogDQpXZSBhbHNvIGZpeGVkIGEgdmVyeSBtaW5v ciBlcnJvciBpbiB0aGUgWUFORyBtb2R1bGUuIA0KIA0KQ2hlZXJzLA0KTWVkDQogDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgaW50ZXJuZXQtDQo+IGRyYWZ0c0BpZXRmLm9yZw0KPiBF bnZvecOpIDogamV1ZGkgOCBvY3RvYnJlIDIwMjAgMTU6NTQNCj4gw4AgOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNCj4gQ2MgOiBkb3RzQGlldGYub3JnDQo+IE9iamV0IDogW0RvdHNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMTMudHh0DQo+IA0KPiANCj4gQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz DQo+IGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBERG9T IE9wZW4gVGhyZWF0IFNpZ25hbGluZyBXRyBvZg0KPiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICAg VGl0bGUgICAgICAgICAgIDogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJl YXQNCj4gU2lnbmFsaW5nIChET1RTKSBUZWxlbWV0cnkNCj4gICAgICAgICBBdXRob3JzICAgICAg ICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRpcnVt YWxlc3dhciBSZWRkeQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEVodWQgRG9yb24NCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICBNZWlsaW5nIENoZW4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBKb24gU2hhbGxvdw0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRv dHMtdGVsZW1ldHJ5LTEzLnR4dA0KPiBQYWdlcyAgICAgICAgICAgOiAxMDcNCj4gRGF0ZSAgICAg ICAgICAgIDogMjAyMC0xMC0wOA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQg YWltcyB0byBlbnJpY2ggRE9UUyBzaWduYWwgY2hhbm5lbCBwcm90b2NvbCB3aXRoDQo+ICAgIHZh cmlvdXMgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgYWxsb3dpbmcgb3B0aW1hbCBEaXN0cmlidXRlZCBE ZW5pYWwtDQo+IG9mLQ0KPiAgICBTZXJ2aWNlIGF0dGFjayBtaXRpZ2F0aW9uLiAgSXQgc3BlY2lm aWVzIHRoZSBub3JtYWwgdHJhZmZpYw0KPiBiYXNlbGluZQ0KPiAgICBhbmQgYXR0YWNrIHRyYWZm aWMgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgYSBET1RTIGNsaWVudCBjYW4gY29udmV5DQo+IHRvDQo+ ICAgIGl0cyBET1RTIHNlcnZlciBpbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0LCB0aGUgbWl0aWdh dGlvbiBzdGF0dXMNCj4gICAgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgYSBET1RTIHNlcnZlciBjYW4g Y29tbXVuaWNhdGUgdG8gYSBET1RTDQo+IGNsaWVudCwNCj4gICAgYW5kIHRoZSBtaXRpZ2F0aW9u IGVmZmljYWN5IHRlbGVtZXRyeSBhdHRyaWJ1dGVzIGEgRE9UUyBjbGllbnQNCj4gY2FuDQo+ICAg IGNvbW11bmljYXRlIHRvIGEgRE9UUyBzZXJ2ZXIuICBUaGUgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMg Y2FuDQo+IGFzc2lzdA0KPiAgICB0aGUgbWl0aWdhdG9yIHRvIGNob29zZSB0aGUgRERvUyBtaXRp Z2F0aW9uIHRlY2huaXF1ZXMgYW5kDQo+IHBlcmZvcm0NCj4gICAgb3B0aW1hbCBERG9TIGF0dGFj ayBtaXRpZ2F0aW9uLg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5Lw0KPiANCj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS0xMw0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMTMNCj4gDQo+IEEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMTMNCj4gDQo+IA0K PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90 c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMN CiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiANCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuDQogDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCiANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQogDQo= ------=_001_NextPart260306307088_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
Hi med,
Is Q= uick-Block specific to Telemetry transfer or general to Signal put method?=

Best Regards,
Meiling

Date: 2020-10-08 2= 2:00
Subject: Re: [Dots] I-D Action: draft-ietf-d= ots-telemetry-13.txt
Hi all,
=0A
&nbs= p;
=0A
We made a minor edit to use the new Block3/4 names as defi= ned by the core WG: Quick-Block1/2.
=0A
 
=0A
We a= lso fixed a very minor error in the YANG module.
=0A
 =0A
Cheers,
=0A
Med
=0A
 
=0A
> --= ---Message d'origine-----
=0A
> De : Dots [mailto:dots-bo= unces@ietf.org] De la part de internet-
=0A
> drafts@ietf.org<= /div>=0A
> Envoy=C3=A9 : jeudi 8 octobre 2020 15:54
=0A> =C3=80 : i-d-announce@ietf.org
=0A
> Cc : do= ts@ietf.org
=0A
> Objet : [Dots] I-D Action: draft-ietf-d= ots-telemetry-13.txt
=0A
>
=0A
>
=0A
&g= t; A New Internet-Draft is available from the on-line Internet-Drafts=0A
> directories.
=0A
> This draft is a work item of = the DDoS Open Threat Signaling WG of
=0A
> the IETF.
=0A<= div>>
=0A
>        = ; Title           : Dist= ributed Denial-of-Service Open Threat
=0A
> Signaling (DOTS) T= elemetry
=0A
>        = Authors         : Mohamed Boucada= ir
=0A
>         =             &n= bsp;     Tirumaleswar Reddy
=0A
> &nb= sp;            = ;             = Ehud Doron
=0A
>       &nbs= p;            =        Meiling Chen
=0A
> &= nbsp;           &nb= sp;            = ; Jon Shallow
=0A
> Filename     &nb= sp;  : draft-ietf-dots-telemetry-13.txt
=0A
> Pages = ;          : 107
=0A> Date          &nb= sp; : 2020-10-08
=0A
>
=0A
> Abstract:
=0A>    This document aims to enrich DOTS signal channel= protocol with
=0A
>    various telemetry attri= butes allowing optimal Distributed Denial-
=0A
> of-
=0A<= div>>    Service attack mitigation.  It specifies t= he normal traffic=0A
> baseline
=0A
>  =   and attack traffic telemetry attributes a DOTS client can convey=0A
> to
=0A
>    its DOTS server in = the mitigation request, the mitigation status
=0A
>  = ;  telemetry attributes a DOTS server can communicate to a DOTS
= =0A
> client,
=0A
>    and the mitigatio= n efficacy telemetry attributes a DOTS client
=0A
> can
= =0A
>    communicate to a DOTS server.  The tel= emetry attributes can
=0A
> assist
=0A
> &nbs= p;  the mitigator to choose the DDoS mitigation techniques and
= =0A
> perform
=0A
>    optimal DDoS atta= ck mitigation.
=0A
>
=0A
>
=0A
> The= IETF datatracker status page for this draft is:
=0A
> https:/= /datatracker.ietf.org/doc/draft-ietf-dots-telemetry/
=0A
> =0A
> There are also htmlized versions available at:
=0A> https://tools.ietf.org/html/draft-ietf-dots-telemetry-13
=0A> https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-13=
=0A
>
=0A
> A diff from the previous version is = available at:
=0A
> https://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-dots-telemetry-13
=0A
>
=0A
>
=0A
= > Please note that it may take a couple of minutes from the time of=0A
> submission until the htmlized version and diff are availabl= e at
=0A
> tools.ietf.org.
=0A
>
=0A
>= ; Internet-Drafts are also available by anonymous FTP at:
=0A
>= ; ftp://ftp.ietf.org/internet-drafts/
=0A
>
=0A
>=
=0A
> _______________________________________________
= =0A
> Dots mailing list
=0A
> Dots@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/dots
=0A
 =0A
_________________________________________________________________= ________________________________________________________
=0A
&nbs= p;
=0A
Ce message et ses pieces jointes peuvent contenir des info= rmations confidentielles ou privilegiees et ne doivent donc
=0A
p= as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
=0A
a l'expediteur e= t le detruire ainsi que les pieces jointes. Les messages electroniques eta= nt susceptibles d'alteration,
=0A
Orange decline toute responsabi= lite si ce message a ete altere, deforme ou falsifie. Merci.
=0A
=  
=0A
This message and its attachments may contain confident= ial or privileged information that may be protected by law;
=0A
t= hey should not be distributed, used or copied without authorisation.
= =0A
If you have received this email in error, please notify the sender= and delete this message and its attachments.
=0A
As emails may b= e altered, Orange is not liable for messages that have been modified, chan= ged or falsified.
=0A
Thank you.
=0A
 
=0A_______________________________________________
=0A
Dots mailing= list
=0A
Dots@ietf.org
=0A
https://www.ietf.org/mailman= /listinfo/dots
=0A
 
=0A
------=_001_NextPart260306307088_=------ From nobody Fri Oct 9 03:25: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 3D57A3A0E55 for ; Fri, 9 Oct 2020 03:25:10 -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 Yi0BNomVlVD4 for ; Fri, 9 Oct 2020 03:25:07 -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 3A0E03A0A3E for ; Fri, 9 Oct 2020 03:25:06 -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 1kQpa8-0006Fm-QP; Fri, 09 Oct 2020 11:25:00 +0100 From: "Jon Shallow" To: "'Meiling Chen'" , , References: <160216522698.30206.2821766755239604133@ietfa.amsl.com>, <10422_1602165604_5F7F1B64_10422_215_1_787AE7BB302AE849A7480A190F8B93303155A3C8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2020100917395360828419@chinamobile.com> In-Reply-To: <2020100917395360828419@chinamobile.com> Date: Fri, 9 Oct 2020 11:25:00 +0100 Message-ID: <010a01d69e26$71650500$542f0f00$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010B_01D69E2E.D32E27F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbMmOxiw9R+ejCxETZmU0sHY+QnwFjt1hPASyeuCSo8WRKsA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-13.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, 09 Oct 2020 10:25:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010B_01D69E2E.D32E27F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Meiling, =20 Interesting question. =20 In my implementation this Quick-Block(1|2) is all handled in libcoap = which does not care whether this is a telemetry update or signal update. =20 I do not think that it should be restricted only to Telemetry. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Meiling Chen Sent: 09 October 2020 10:40 To: mohamed.boucadair; dots Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-13.txt =20 Hi med, Is Quick-Block specific to Telemetry transfer or general to Signal put = method? Best Regards, Meiling =20 From: mohamed.boucadair@orange.com Date: 2020-10-08 22:00 To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-13.txt Hi all,=20 =20 We made a minor edit to use the new Block3/4 names as defined by the = core WG: Quick-Block1/2.=20 =20 We also fixed a very minor error in the YANG module.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=C3=A9 : jeudi 8 octobre 2020 15:54 > =C3=80 : i-d-announce@ietf.org > Cc : dots@ietf.org > Objet : [Dots] I-D Action: draft-ietf-dots-telemetry-13.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 > Jon Shallow > Filename : draft-ietf-dots-telemetry-13.txt > Pages : 107 > Date : 2020-10-08 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal Distributed Denial- > of- > Service 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-13 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-13 >=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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots =20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_010B_01D69E2E.D32E27F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Meiling,

 

Interesting question.

 

In my implementation this Quick-Block(1|2) is all handled in libcoap = which does not care whether this is a telemetry update or signal = update.

 

I do not think that it should be restricted only to = Telemetry.

 

Regards

 

Jon

 

From:= Dots = [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Meiling = Chen
Sent: 09 October 2020 10:40
To: = mohamed.boucadair; dots
Subject: Re: [Dots] I-D Action: = draft-ietf-dots-telemetry-13.txt

 

Hi = med,

Is Quick-Block specific to Telemetry = transfer or general to Signal put = method?



Best = Regards,

Meiling

=

 

D= ate:&= nbsp;2020-10-08 22:00

T= o:&= nbsp;dots@ietf.org

S= ubject:&= nbsp;Re: [Dots] I-D Action: = draft-ietf-dots-telemetry-13.txt

<= div>

Hi all, =

 

<= p class=3DMsoNormal>We made a minor edit to use the new = Block3/4 names as defined by the core WG: Quick-Block1/2. =

 

<= p class=3DMsoNormal>We also fixed a very minor error in the = YANG module.

 

<= p class=3DMsoNormal>Cheers,

=

Med

 

<= p class=3DMsoNormal>> -----Message = d'origine-----

> De : Dots = [mailto:dots-bounces@ietf.org] De la part de = internet-

> = drafts@ietf.org

> Envoy=C3=A9 : jeudi 8 octobre = 2020 15:54

> =C3=80 : = i-d-announce@ietf.org

> Cc : = dots@ietf.org

> Objet : [Dots] I-D Action: = draft-ietf-dots-telemetry-13.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.

> =

>      =    = Title           : = Distributed Denial-of-Service Open = Threat

> Signaling (DOTS) = Telemetry

>      =    Authors         : = Mohamed Boucadair

>      =             &= nbsp;        Tirumaleswar = Reddy

>      =             &= nbsp;        Ehud = Doron

>      =             &= nbsp;        Meiling = Chen

>      =             &= nbsp;        Jon = Shallow

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

> = Pages           : = 107

> = Date            : = 2020-10-08

> =

> = Abstract:

>    This document = aims to enrich DOTS signal channel protocol = with

>    various = telemetry attributes allowing optimal Distributed = Denial-

> = of-

>    Service 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-13

> = https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-13

> =

> A diff from the previous version = is available at:

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

> =

> =

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

> =

> =

> = _______________________________________________

> Dots mailing = list

> = Dots@ietf.org

> = https://www.ietf.org/mailman/listinfo/dots

 

<= p class=3DMsoNormal>________________________________________= _________________________________________________________________________= ________

 

<= p class=3DMsoNormal>Ce message et ses pieces jointes = peuvent contenir des informations confidentielles ou privilegiees et ne = doivent donc

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

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

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

 

<= p class=3DMsoNormal>This message and its attachments may = contain confidential or privileged information that may be protected by = law;

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

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

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

Thank = you.

 

<= p class=3DMsoNormal>________________________________________= _______

Dots mailing = list

Dots@ietf.org

https://www.ietf.org/mailman/listinfo/do= ts

 

=
------=_NextPart_000_010B_01D69E2E.D32E27F0-- From nobody Fri Oct 9 06:06:45 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C7D3A0F2B for ; Fri, 9 Oct 2020 06:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWNqDhXi6gcu for ; Fri, 9 Oct 2020 06:06:41 -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 D446A3A0F2A for ; Fri, 9 Oct 2020 06:06:40 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4C77cv1m1dzBsTC; Fri, 9 Oct 2020 15:06:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602248799; bh=5PGV8950eikKDOCRtpERfSvGuTIctq4LPLegL7peoOg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=a1MBEzOrHg2e1kt5GP0X9Lz8djCsykqEAnAaqBAY66m0aFzHS16k61pA5ke76mEGY 1HGG0olsnAzFipmlYa3OwqWKUvASxty6iC56aqjG+10bkySaoEBGcBypNvWS0PSUUe Ahn7hn7zfx/9lZV8ujG/YHUMv9V9+TAuHOnsKBxClbQMvxOhNkjPPpH5aCXA402+mJ F099TqBV6BPHBO5lZOtPI/Lk0pyKs3A9ouW/qvf5b3VwAfALW5KuFbSMMvckeh/FL3 sb9NjXm5NXXNx2dHZn6piCqgS63x7gYlr8x0wRbPSFF+NpALOk4oE2Pbq0/XCUIjJ0 FiLip1U6G4avQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4C77cv0MtkzBrLb; Fri, 9 Oct 2020 15:06:39 +0200 (CEST) From: To: Jon Shallow , 'Meiling Chen' , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-13.txt Thread-Index: AQIbMmOxiw9R+ejCxETZmU0sHY+QnwFjt1hPASyeuCSo8WRKsIAALcXg Date: Fri, 9 Oct 2020 13:06:38 +0000 Message-ID: <13589_1602248799_5F80605F_13589_318_1_787AE7BB302AE849A7480A190F8B93303155BC9C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160216522698.30206.2821766755239604133@ietfa.amsl.com>, <10422_1602165604_5F7F1B64_10422_215_1_787AE7BB302AE849A7480A190F8B93303155A3C8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2020100917395360828419@chinamobile.com> <010a01d69e26$71650500$542f0f00$@jpshallow.com> In-Reply-To: <010a01d69e26$71650500$542f0f00$@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_787AE7BB302AE849A7480A190F8B93303155BC9COPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-13.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, 09 Oct 2020 13:06:43 -0000 --_000_787AE7BB302AE849A7480A190F8B93303155BC9COPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFncmVlIHdpdGggSm9uLg0KDQpXZSBtYXkgY29uc2lkZXIgYWRkaW5nIHNv bWUgdGV4dCB0byB0aGUgODc4MmJpcyB1c2luZyB0aGUgc2FtZSB3b3JkaW5nIG9mIHRoZSB0ZWxl bWV0cnkgSS1EOiBubyBub3JtYXRpdmUgbGFuZ3VhZ2UuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IEpvbiBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCkVudm95w6kg OiB2ZW5kcmVkaSA5IG9jdG9icmUgMjAyMCAxMjoyNQ0Kw4AgOiAnTWVpbGluZyBDaGVuJyA8Y2hl bm1laWxpbmdAY2hpbmFtb2JpbGUuY29tPjsgQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiA8bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGRvdHNAaWV0Zi5vcmcNCk9iamV0IDogUkU6IFtE b3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTEzLnR4dA0KDQpIaSBN ZWlsaW5nLA0KDQpJbnRlcmVzdGluZyBxdWVzdGlvbi4NCg0KSW4gbXkgaW1wbGVtZW50YXRpb24g dGhpcyBRdWljay1CbG9jaygxfDIpIGlzIGFsbCBoYW5kbGVkIGluIGxpYmNvYXAgd2hpY2ggZG9l cyBub3QgY2FyZSB3aGV0aGVyIHRoaXMgaXMgYSB0ZWxlbWV0cnkgdXBkYXRlIG9yIHNpZ25hbCB1 cGRhdGUuDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgb25s eSB0byBUZWxlbWV0cnkuDQoNClJlZ2FyZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzpp ZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNZWlsaW5nIENo ZW4NClNlbnQ6IDA5IE9jdG9iZXIgMjAyMCAxMDo0MA0KVG86IG1vaGFtZWQuYm91Y2FkYWlyOyBk b3RzDQpTdWJqZWN0OiBSZTogW0RvdHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy10ZWxl bWV0cnktMTMudHh0DQoNCkhpIG1lZCwNCklzIFF1aWNrLUJsb2NrIHNwZWNpZmljIHRvIFRlbGVt ZXRyeSB0cmFuc2ZlciBvciBnZW5lcmFsIHRvIFNpZ25hbCBwdXQgbWV0aG9kPw0KDQpCZXN0IFJl Z2FyZHMsDQpNZWlsaW5nDQoNCkZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpEYXRlOiAyMDIwLTEwLTA4IDIyOjAw DQpUbzogZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb RG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS0xMy50eHQNCkhpIGFs bCwNCg0KV2UgbWFkZSBhIG1pbm9yIGVkaXQgdG8gdXNlIHRoZSBuZXcgQmxvY2szLzQgbmFtZXMg YXMgZGVmaW5lZCBieSB0aGUgY29yZSBXRzogUXVpY2stQmxvY2sxLzIuDQoNCldlIGFsc28gZml4 ZWQgYSB2ZXJ5IG1pbm9yIGVycm9yIGluIHRoZSBZQU5HIG1vZHVsZS4NCg0KQ2hlZXJzLA0KTWVk DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogRG90cyBbbWFpbHRvOmRv dHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBpbnRlcm5ldC0NCj4gZHJhZnRzQGll dGYub3JnPG1haWx0bzpkcmFmdHNAaWV0Zi5vcmc+DQo+IEVudm95w6kgOiBqZXVkaSA4IG9jdG9i cmUgMjAyMCAxNTo1NA0KPiDDgCA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnPg0KPiBDYyA6IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5v cmc+DQo+IE9iamV0IDogW0RvdHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0 cnktMTMudHh0DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cgb2YN Cj4gdGhlIElFVEYuDQo+DQo+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogRGlzdHJpYnV0ZWQg RGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCj4gU2lnbmFsaW5nIChET1RTKSBUZWxlbWV0 cnkNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIEVodWQgRG9yb24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNZWls aW5nIENoZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBKb24gU2hhbGxvdw0KPiBGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTEzLnR4dA0KPiBQYWdlcyAg ICAgICAgICAgOiAxMDcNCj4gRGF0ZSAgICAgICAgICAgIDogMjAyMC0xMC0wOA0KPg0KPiBBYnN0 cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBhaW1zIHRvIGVucmljaCBET1RTIHNpZ25hbCBjaGFu bmVsIHByb3RvY29sIHdpdGgNCj4gICAgdmFyaW91cyB0ZWxlbWV0cnkgYXR0cmlidXRlcyBhbGxv d2luZyBvcHRpbWFsIERpc3RyaWJ1dGVkIERlbmlhbC0NCj4gb2YtDQo+ICAgIFNlcnZpY2UgYXR0 YWNrIG1pdGlnYXRpb24uICBJdCBzcGVjaWZpZXMgdGhlIG5vcm1hbCB0cmFmZmljDQo+IGJhc2Vs aW5lDQo+ICAgIGFuZCBhdHRhY2sgdHJhZmZpYyB0ZWxlbWV0cnkgYXR0cmlidXRlcyBhIERPVFMg Y2xpZW50IGNhbiBjb252ZXkNCj4gdG8NCj4gICAgaXRzIERPVFMgc2VydmVyIGluIHRoZSBtaXRp Z2F0aW9uIHJlcXVlc3QsIHRoZSBtaXRpZ2F0aW9uIHN0YXR1cw0KPiAgICB0ZWxlbWV0cnkgYXR0 cmlidXRlcyBhIERPVFMgc2VydmVyIGNhbiBjb21tdW5pY2F0ZSB0byBhIERPVFMNCj4gY2xpZW50 LA0KPiAgICBhbmQgdGhlIG1pdGlnYXRpb24gZWZmaWNhY3kgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMg YSBET1RTIGNsaWVudA0KPiBjYW4NCj4gICAgY29tbXVuaWNhdGUgdG8gYSBET1RTIHNlcnZlci4g IFRoZSB0ZWxlbWV0cnkgYXR0cmlidXRlcyBjYW4NCj4gYXNzaXN0DQo+ICAgIHRoZSBtaXRpZ2F0 b3IgdG8gY2hvb3NlIHRoZSBERG9TIG1pdGlnYXRpb24gdGVjaG5pcXVlcyBhbmQNCj4gcGVyZm9y bQ0KPiAgICBvcHRpbWFsIEREb1MgYXR0YWNrIG1pdGlnYXRpb24uDQo+DQo+DQo+IFRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5Lw0KPg0KPiBU aGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTEzDQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRy eS0xMw0KPg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMt dGVsZW1ldHJ5LTEzDQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRmLm9y Zy4NCj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1h aWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGlldGYub3JnPg0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkRvdHMgbWFpbGluZyBsaXN0DQpEb3RzQGlldGYub3JnPG1haWx0bzpEb3RzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KCg== --_000_787AE7BB302AE849A7480A190F8B93303155BC9COPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWljcm9zb2Z0IFlh SGVpIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJcQE1pY3Jvc29mdCBZYUhlaSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQg MiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRl eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIGFsbCwNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFncmVlIHdp dGggSm9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PldlIG1heSBjb25zaWRlciBhZGRpbmcgc29tZSB0ZXh0IHRvIHRoZSA4NzgyYmlzIHVzaW5nIHRo ZSBzYW1lIHdvcmRpbmcgb2YgdGhlIHRlbGVtZXRyeSBJLUQ6IG5vIG5vcm1hdGl2ZSBsYW5ndWFn ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVl cnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbiBTaGFsbG93 IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJz cDs6PC9iPiB2ZW5kcmVkaSA5IG9jdG9icmUgMjAyMCAxMjoyNTxicj4NCjxiPsOAJm5ic3A7Ojwv Yj4gJ01laWxpbmcgQ2hlbicgJmx0O2NoZW5tZWlsaW5nQGNoaW5hbW9iaWxlLmNvbSZndDs7IEJP VUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20m Z3Q7OyBkb3RzQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSRTogW0RvdHNdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMTMudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBNZWlsaW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbnRlcmVzdGluZyBx dWVzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4gbXkgaW1wbGVtZW50YXRpb24gdGhpcyBRdWljay1CbG9j aygxfDIpIGlzIGFsbCBoYW5kbGVkIGluIGxpYmNvYXAgd2hpY2ggZG9lcyBub3QgY2FyZSB3aGV0 aGVyIHRoaXMgaXMgYSB0ZWxlbWV0cnkgdXBkYXRlIG9yIHNpZ25hbCB1cGRhdGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkkgZG8gbm90IHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgb25seSB0byBU ZWxlbWV0cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IERvdHMgWzxhIGhyZWY9Im1haWx0 bzppZXRmLXN1cGpwcy1kb3RzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppZXRmLXN1cGpwcy1k b3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NZWlsaW5nIENo ZW48YnI+DQo8Yj5TZW50OjwvYj4gMDkgT2N0b2JlciAyMDIwIDEwOjQwPGJyPg0KPGI+VG86PC9i PiBtb2hhbWVkLmJvdWNhZGFpcjsgZG90czxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMTMudHh0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5IaSBtZWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5JcyBRdWljay1CbG9jayBzcGVjaWZpYyB0byBUZWxlbWV0cnkgdHJhbnNmZXIgb3Ig Z2VuZXJhbCB0byBTaWduYWwgcHV0IG1ldGhvZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5C ZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5NZWlsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDo2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+RGF0ZTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDsyMDIwLTEwLTA4Jm5ic3A7MjI6MDA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ VG86PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7UmU6IFtEb3RzXSBJLUQNCiBBY3Rpb246IGRyYWZ0LWlldGYtZG90 cy10ZWxlbWV0cnktMTMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpIGFsbCwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5XZSBtYWRlIGEgbWlu b3IgZWRpdCB0byB1c2UgdGhlIG5ldyBCbG9jazMvNCBuYW1lcyBhcyBkZWZpbmVkIGJ5IHRoZSBj b3JlIFdHOiBRdWljay1CbG9jazEvMi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5XZSBhbHNvIGZpeGVkIGEgdmVyeSBtaW5vciBlcnJvciBp biB0aGUgWUFORyBtb2R1bGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IERl Jm5ic3A7OiBEb3RzIFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBpbnRlcm5ldC08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxh IGhyZWY9Im1haWx0bzpkcmFmdHNAaWV0Zi5vcmciPmRyYWZ0c0BpZXRmLm9yZzwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgRW52b3nD qSZuYnNwOzogamV1ZGkgOCBvY3RvYnJlIDIwMjAgMTU6NTQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgw4AmbmJzcDs6DQo8YSBocmVmPSJt YWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IENj Jm5ic3A7Og0KPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 IE9iamV0Jm5ic3A7OiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRy eS0xMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBkaXJlY3Rvcmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cgb2Y8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgdGhlIElFVEYuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGl0bGUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg OiBEaXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv ZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBTaWduYWxpbmcgKERP VFMpIFRlbGVtZXRyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDogTW9oYW1lZCBCb3VjYWRhaXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVGlydW1hbGVzd2FyIFJlZGR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEVodWQgRG9yb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTWVpbGluZyBDaGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEpvbiBTaGFsbG93PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS0xMy50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgUGFnZXMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg OiAxMDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDsgRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIwMjAtMTAtMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBBYnN0cmFjdDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhpcyBkb2N1bWVudCBhaW1zIHRvIGVucmljaCBET1RTIHNpZ25hbCBjaGFubmVsIHBy b3RvY29sIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFyaW91cyB0ZWxlbWV0cnkgYXR0cmlidXRl cyBhbGxvd2luZyBvcHRpbWFsIERpc3RyaWJ1dGVkIERlbmlhbC08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlh SGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgb2YtPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNlcnZpY2UgYXR0YWNrIG1pdGlnYXRpb24uJm5ic3A7IEl0IHNwZWNpZmllcyB0aGUgbm9y bWFsIHRyYWZmaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsgYmFzZWxpbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIGF0dGFjayB0cmFmZmlj IHRlbGVtZXRyeSBhdHRyaWJ1dGVzIGEgRE9UUyBjbGllbnQgY2FuIGNvbnZleTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyB0bzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtN aWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBpdHMgRE9UUyBzZXJ2ZXIgaW4gdGhlIG1pdGlnYXRpb24gcmVxdWVzdCwgdGhl IG1pdGlnYXRpb24gc3RhdHVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRlbGVtZXRyeSBhdHRyaWJ1dGVz IGEgRE9UUyBzZXJ2ZXIgY2FuIGNvbW11bmljYXRlIHRvIGEgRE9UUzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQg WWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBjbGllbnQsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGFuZCB0aGUgbWl0aWdhdGlvbiBlZmZpY2FjeSB0ZWxlbWV0cnkgYXR0cmlidXRl cyBhIERPVFMgY2xpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7IGNhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tdW5pY2F0ZSB0byBhIERP VFMgc2VydmVyLiZuYnNwOyBUaGUgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgY2FuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IGFzc2lzdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgbWl0aWdhdG9yIHRvIGNob29zZSB0aGUgRERvUyBtaXRpZ2F0aW9u IHRlY2huaXF1ZXMgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7IHBlcmZvcm08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW1hbCBERG9TIGF0 dGFjayBtaXRpZ2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS88L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlh SGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMTMiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTEzPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv ZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtdGVsZW1l dHJ5LTEzIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt ZG90cy10ZWxlbWV0cnktMTM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jmd0Ow0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMTMiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtdGVsZW1ldHJ5LTEzPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv ZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mZ3Q7IHRvb2xzLmlldGYub3JnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IERvdHMgbWFp bGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mZ3Q7DQo8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90c0BpZXRmLm9yZzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+cGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+RG90cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIj5Eb3RzQGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1s Pg0K --_000_787AE7BB302AE849A7480A190F8B93303155BC9COPEXCAUBMA2corp_-- From nobody Sun Oct 11 17:09:44 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 2BC873A0A25; Sun, 11 Oct 2020 17:09:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: last-call@ietf.org, dots@ietf.org, draft-ietf-dots-server-discovery.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160246137613.594.10649805135544482452@ietfa.amsl.com> Reply-To: Kyle Rose Date: Sun, 11 Oct 2020 17:09:36 -0700 Archived-At: Subject: [Dots] Tsvart last call review of draft-ietf-dots-server-discovery-11 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 00:09:36 -0000 Reviewer: Kyle Rose Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. >From the perspective of the transport area, this document is Ready: the specification of new SRV application protocol names appears to comply with current TSVART guidance. That said, I have some questions and comments that may or may not be of interest to the transport ADs: * Section 4 says: The discovery method is reiterated by a DOTS agent upon the following events: o Expiry of a a validity timer (e.g., DHCP lease, DNS TTL) associated with a discovered DOTS agent. >From my reading, rendezvous information for the DOTS server is "pushed" to the client via DHCP, so it's not clear the above is actionable. Is it simply the case that a client should use the DOTS server assigned in the most recent lease? * Section 5.1 describes a trust mechanism that can charitably be described as "hopeful". Fundamentally, the security of TLS relies on a three-legged stool: (1) The integrity of the X.509 server certificate issuance procedures (2) The cryptographic trust anchors configured in a client (3) Pre-established trust in the server's identity, which must match a ServerAltName in the signed server certificate The security considerations section briefly alludes to the problems with using DHCP via reference to security considerations sections in DHCP RFCs, but I don't think that quite does justice to the problem here. TLS is cripped by a failure in any of the above: * A trusted CA wrongly issues a certificate to a third party with the ability to hijack rendezvous (e.g., through BGP or DNS attacks) * A user's certificate store is augmented by a CA under the control of an adversary * Via a mistaken or injected hostname, a user establishes a connection to the wrong endpoint that nonetheless has a legitimately-issued certificate Using DHCP, an inherently insecure protocol, to inform DOTS clients of the hostname of DOTS server knocks this third leg out, calling into question the entire mechanism. Measures can be taken to mitigate this risk, such as configuring clients with a domain whitelist (e.g., accept DOTS names only within a particular domain), configuring clients with a set of private CAs as trust anchors, configuring border routers with network-layer packet filtering for DOTS traffic, etc., but ultimately without some preconfiguration, clients are at the mercy of rogue DHCP. * Section 5.2.1 has: The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to configure a name of the peer DOTS agent. The format of this option is illustrated in Figure 6. Code Length Peer DOTS agent name +-----+-----+-----+-----+-----+-----+-----+-- |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-- The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding. Is the final label zero-length? Other parts of the DHCPv4 protocol terminate domain names with a zero-length label. What if a zero-length label appears in some s_i other than the final one? * Section 7 says: This document does not define any keys; the TXT record of a DNS-SD service is thus empty (Section 6 of [RFC6763]). RFC 6763 says that an empty TXT record MUST be included alongside the SRV record where DNS-SD is concerned. Should normative language be used here, or should we rely on the normative reference in case that guidance changes in the future? From nobody Mon Oct 12 04:21: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 3F0393A140C; Mon, 12 Oct 2020 04:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHlzl9Y5_WXh; Mon, 12 Oct 2020 04:20:56 -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 8C7E23A1410; Mon, 12 Oct 2020 04:20:56 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4C8x7V5lR7zBslb; Mon, 12 Oct 2020 13:20:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602501654; bh=jCTgrOYYdXADOcVBCdv9Vio5uLTzv2Al8u90lJCKHDU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Y06uZORiFIufm2D48IM5DcVGWCqs5XQam73SIBaRLAdg4U4lec9rI0jDSS1y/hyxx SaAVHU+j/9X+7Dd4GBEJECk4WLaQMxClgUaK/uikY1ufjgA2xNWkEZ1H9U34rfiALC nR1DGpvcQEFBczp8cr+IqPmSh3Cs7fjS21+f0r13T2DPVwB/GfZ+m0yn9q2+FIaG2v CKArUUh3kalyxvwNcsHGggUJVSdrAyp9oizzLPNnREmAVXAWwCahtnENCTlWNM3NX6 eNlLtrypuCGOtiA4hIbYa6et9FaNuV7e/2wz/hXVJTiB4Q6wsEHUkIxO1qrWdYJQzU oQ0kvCYNqC4Uw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4C8x7V4h5Tz3wc6; Mon, 12 Oct 2020 13:20:54 +0200 (CEST) From: To: Valery Smyslov , "dots@ietf.org" CC: "dots-chairs@ietf.org" , "draft-ietf-dots-rfc8782-bis@ietf.org" Thread-Topic: WGLC for draft-ietf-dots-rfc8782-bis-01 Thread-Index: Adab1OgBrqjjS4NlQFeILndcywZANQEsm6ww Date: Mon, 12 Oct 2020 11:20:53 +0000 Message-ID: <6541_1602501654_5F843C16_6541_51_9_787AE7BB302AE849A7480A190F8B93303155DA30@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> In-Reply-To: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 12 Oct 2020 11:20:58 -0000 Hi all, We are considering making this change in Section 7.2 (when TLS1.3 is suppor= ted): =3D=3D NEW: (D)TLS 1.3 has support for PKI certificate compression [I-D.ietf-tls-certificate-compression] which can reduce the initial setup time when using PKI. The DOTS peers MUST negotiate this extension as per Section 3 of [I-D.ietf-tls-certificate-compression]. =3D=3D Please note that: * I-D.ietf-tls-certificate-compression will be published as RFC8879 * I-D.ietf-tls-certificate-compression has a dependency on draft-kucherawy-= rfc8478bis which is in the RFC Editor queue as well but with a state set to= "IESG". After checking with Murray, it seems that the issue will be cleare= d soon and the document will be back to the AUTH48 state. See https://www.r= fc-editor.org/auth48/rfc8878=20 Comments are welcome. Cheers, Med > -----Message d'origine----- > De=A0: Valery Smyslov [mailto:valery@smyslov.net] > Envoy=E9=A0: mardi 6 octobre 2020 13:43 > =C0=A0: dots@ietf.org > Cc=A0: dots-chairs@ietf.org; draft-ietf-dots-rfc8782-bis@ietf.org > Objet=A0: WGLC for draft-ietf-dots-rfc8782-bis-01 >=20 > Hi, >=20 > this message starts a two-week working group last call for draft- > ietf-dots-rfc8782-bis-01, which will end on Wednesday, October 21. > Please, review the draft carefully and send your comments to the > mailing list. >=20 > Regards, > Frank & Valery. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Oct 12 04:55: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 F3AF03A0E7D for ; Mon, 12 Oct 2020 04:55:42 -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=unavailable 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 oXjZX2onTvX7 for ; Mon, 12 Oct 2020 04:55:40 -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 360B83A0E82 for ; Mon, 12 Oct 2020 04:55: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 1kRwQS-0008Uz-7a; Mon, 12 Oct 2020 12:55:36 +0100 From: To: , "'Valery Smyslov'" , Cc: , References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> <6541_1602501654_5F843C16_6541_51_9_787AE7BB302AE849A7480A190F8B93303155DA30@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <6541_1602501654_5F843C16_6541_51_9_787AE7BB302AE849A7480A190F8B93303155DA30@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 12 Oct 2020 12:55:33 +0100 Message-ID: <035801d6a08e$96db1a30$c4914e90$@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: AQHaSW9CC59W3Vb/kWpl9RTUAcwqaQDTd7gwqYXoLlA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 12 Oct 2020 11:55:43 -0000 Hi Med, I am not convinced that we can use MUST as in "peers MUST negotiate" as = this has not been significantly adopted yet in the major TLS libraries (I = have only found one TLS library in my searches) and so wonder if it should be = a SHOULD. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 12 October 2020 12:21 > To: Valery Smyslov; dots@ietf.org > Cc: dots-chairs@ietf.org; draft-ietf-dots-rfc8782-bis@ietf.org > Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 >=20 > Hi all, >=20 > We are considering making this change in Section 7.2 (when TLS1.3 is > supported): >=20 > =3D=3D > NEW: > (D)TLS 1.3 has support for PKI certificate compression > [I-D.ietf-tls-certificate-compression] which can reduce the initial > setup time when using PKI. The DOTS peers MUST negotiate this > extension as per Section 3 of = [I-D.ietf-tls-certificate-compression]. > =3D=3D >=20 > Please note that: > * I-D.ietf-tls-certificate-compression will be published as RFC8879 > * I-D.ietf-tls-certificate-compression has a dependency on draft-kucherawy- > rfc8478bis which is in the RFC Editor queue as well but with a state = set to > "IESG". After checking with Murray, it seems that the issue will be cleared > soon and the document will be back to the AUTH48 state. See > https://www.rfc-editor.org/auth48/rfc8878 >=20 > Comments are welcome. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Valery Smyslov [mailto:valery@smyslov.net] > > Envoy=E9=A0: mardi 6 octobre 2020 13:43 > > =C0=A0: dots@ietf.org > > Cc=A0: dots-chairs@ietf.org; draft-ietf-dots-rfc8782-bis@ietf.org > > Objet=A0: WGLC for draft-ietf-dots-rfc8782-bis-01 > > > > Hi, > > > > this message starts a two-week working group last call for draft- > > ietf-dots-rfc8782-bis-01, which will end on Wednesday, October 21. > > Please, review the draft carefully and send your comments to the > > mailing list. > > > > Regards, > > Frank & Valery. >=20 >=20 > ___________________________________________________________________ > ______________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou > falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Oct 12 07:54:00 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 AF36B3A1535; Mon, 12 Oct 2020 07:53:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zhen Cao via Datatracker To: Cc: draft-ietf-dots-server-discovery.all@ietf.org, last-call@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160251443866.28127.2696320816235439108@ietfa.amsl.com> Reply-To: Zhen Cao Date: Mon, 12 Oct 2020 07:53:58 -0700 Archived-At: Subject: [Dots] Intdir last call partial review of draft-ietf-dots-server-discovery-11 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 14:53:59 -0000 Review is partially done. Another assignment may be needed to complete it. Reviewer: Zhen Cao Review result: Ready with Nits Reviewer: Zhen Cao Review result: Ready with Nits Thanks the authors for the document. DOTS server discovery is important to the functioning of the whole system. Important: I read Bernie's eary quick review (saying not a full one) for the 01 version [*] and the comments had been addressed in 02 version. And I think our AD @Eric needs to check if there is a need for further DHC doctor review. (although I checked there were not much changed on the DHCP parts from r02 to r11) . [*]https://github.com/boucadair/draft-ietf-dots-discovery/issues/1 I think most of the other parts looks quite ready except: a) Section 5.1.2 on the configuration of the ipv4-mapped IPv6 address. old: Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) are allowed to be included in this option. I do not know why this is particularly mentioned here given there are many types of IPv6 address. I think it 's better to remove this statement since there are many issues configuring IPv4-mapped address directly. Some systems will disable (by default) support for internal IPv4-mapped IPv6 addresses. Some implementations of dual-stack do not allow IPv4-mapped IPv6 addresses to be used for interoperability between IPv4 and IPv6 applications. [RFC4038]. Such discussions do not have to be present here. b) the first sentence of the abstract: s/Districuted/Distributed. From nobody Mon Oct 12 14:54: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 979663A0A68; Mon, 12 Oct 2020 14:54:57 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9qwnq70qLGY4; Mon, 12 Oct 2020 14:54:56 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CE3073A0A4A; Mon, 12 Oct 2020 14:54:55 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09CLsmkx018441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Oct 2020 17:54:53 -0400 Date: Mon, 12 Oct 2020 14:54:47 -0700 From: Benjamin Kaduk To: supjps-ietf@jpshallow.com Cc: mohamed.boucadair@orange.com, "'Valery Smyslov'" , dots@ietf.org, dots-chairs@ietf.org, draft-ietf-dots-rfc8782-bis@ietf.org Message-ID: <20201012215447.GF1212@kduck.mit.edu> References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> <6541_1602501654_5F843C16_6541_51_9_787AE7BB302AE849A7480A190F8B93303155DA30@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <035801d6a08e$96db1a30$c4914e90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <035801d6a08e$96db1a30$c4914e90$@jpshallow.com> Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 12 Oct 2020 21:54:58 -0000 On Mon, Oct 12, 2020 at 12:55:33PM +0100, supjps-ietf@jpshallow.com wrote: > Hi Med, > > I am not convinced that we can use MUST as in "peers MUST negotiate" as this > has not been significantly adopted yet in the major TLS libraries (I have > only found one TLS library in my searches) and so wonder if it should be a > SHOULD. It does seem a pretty significant change for what was originally just going to be a small bis. -Ben P.S. I had heard last week that draft-kucherawy-rfc8478bis was supposed to be in AUTH48-DONE just waiting on IANA to complete their actions, so it was surprising to see it was in state 'IESG'! From nobody Mon Oct 12 16:47:58 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 372CE3A0DD4; Mon, 12 Oct 2020 16:47:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Nagendra Nainar via Datatracker To: Cc: draft-ietf-dots-server-discovery.all@ietf.org, last-call@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160254645915.19164.9668371473019350974@ietfa.amsl.com> Reply-To: Nagendra Nainar Date: Mon, 12 Oct 2020 16:47:39 -0700 Archived-At: Subject: [Dots] Opsdir last call review of draft-ietf-dots-server-discovery-11 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 23:47:46 -0000 Reviewer: Nagendra Nainar Review result: Has Nits Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts per guidelines in RFC5706. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Version: draft-ietf-dots-server-discovery-11 Overall Summary: This draft is a standard track proposing the DOTS server discovery procedure. The draft proposes 3 different discovery options and sufficiently clarify the procedure required when one or more of the options co-exist. The draft further defines the protocol extensions required to carry the details in DHCPv4, DHCPv6 options and for DNS service discovery. Overall this is a well written document. Some ambiguity observed that needs attention are listed below: --> Section 5 states the below: " The list of the IP addresses returned by DHCP servers is typically used to feed the DOTS server selection procedure or to provide DOTS agents with primary and backup IP addresses of their peer DOTS agents." While the DHCP options replies with the bunch of IP/Ipv6 address of the peer DOTS agents. Is there any mechanism specified (or required) to select the primary/backup?. Or is it a local matter?. ==> The below text suggest to discard multicast and loopback address. While it is obvious for global scoped address, how would the node behave if it receives other reserved range address (such as Discard)?. Can it accept link-local address?. The DHCP client MUST silently discard multicast and host loopback addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. ==> It will be good if you can name the tables. Few observations below: s/Districuted/Distributed Thanks, Nagendra From nobody Mon Oct 12 22:24:45 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DA43A0E3E; Mon, 12 Oct 2020 22:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISjuHqRGNRu4; Mon, 12 Oct 2020 22:24:42 -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 60E303A0E3D; Mon, 12 Oct 2020 22:24:42 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4C9PB04Q7bz7vG4; Tue, 13 Oct 2020 07:24:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602566680; bh=EAyeFNghfvENqLPe17oSAdjo+1sHIZ9dkZpr86KsUfU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=k8oqO5JXWT6gGydLTQEs4P+3jIPRpxigMdN4EkmJ0Ls7vXlaSqbGPB0HInQYVZdt5 GiFews3nYM6GyAsfSQmHol8XREl1ST29CCKgO1IDRMD5IvhH1bmRW65S2Tpu0QhA0z lKxAlk90rtHua6L9RTo/Rkc0qAGg74IZX9EQgg2g2eI47+mE8WEzBAgEN6sxla44Pi GpU3onTxzdsVEuQKbskJSjYaRZnYGIFmfj4K/cP2+YJXMEeFem4mmlx6ZfHxpYSm4c hAX3H/pNoSX1wwn80coCMGosy8r53VuJd5YWQzfHAnLgm0oWdbf6UVcro4aIkZQMC+ eJ+Z/zAYXqSrw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4C9PB0309rzCqlY; Tue, 13 Oct 2020 07:24:40 +0200 (CEST) From: To: Benjamin Kaduk , "supjps-ietf@jpshallow.com" CC: 'Valery Smyslov' , "dots@ietf.org" , "dots-chairs@ietf.org" , "draft-ietf-dots-rfc8782-bis@ietf.org" Thread-Topic: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 Thread-Index: AQHWoOJVWFivH7mJP0+arOaNX+7Jj6mU/zNQ Date: Tue, 13 Oct 2020 05:24:39 +0000 Message-ID: <16481_1602566680_5F853A18_16481_263_1_787AE7BB302AE849A7480A190F8B93303155F144@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> <6541_1602501654_5F843C16_6541_51_9_787AE7BB302AE849A7480A190F8B93303155DA30@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <035801d6a08e$96db1a30$c4914e90$@jpshallow.com> <20201012215447.GF1212@kduck.mit.edu> In-Reply-To: <20201012215447.GF1212@kduck.mit.edu> 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] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 13 Oct 2020 05:24:45 -0000 Hi Ben, Fair point.=20 If this is deviating from our initial plan for preparing the bis, I'm with = making no such change. =20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: lundi 12 octobre 2020 23:55 > =C0=A0: supjps-ietf@jpshallow.com > Cc=A0: BOUCADAIR Mohamed TGI/OLN ; > 'Valery Smyslov' ; dots@ietf.org; dots- > chairs@ietf.org; draft-ietf-dots-rfc8782-bis@ietf.org > Objet=A0: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 >=20 > On Mon, Oct 12, 2020 at 12:55:33PM +0100, supjps-ietf@jpshallow.com > wrote: > > Hi Med, > > > > I am not convinced that we can use MUST as in "peers MUST > negotiate" > > as this has not been significantly adopted yet in the major TLS > > libraries (I have only found one TLS library in my searches) and > so > > wonder if it should be a SHOULD. >=20 > It does seem a pretty significant change for what was originally > just going to be a small bis. >=20 > -Ben >=20 > P.S. I had heard last week that draft-kucherawy-rfc8478bis was > supposed to be in AUTH48-DONE just waiting on IANA to complete their > actions, so it was surprising to see it was in state 'IESG'! ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Oct 12 23:02: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 B9AEF3A0E69; Mon, 12 Oct 2020 23:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zagb1J1UXURx; Mon, 12 Oct 2020 23:02:50 -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 DED613A0D2A; Mon, 12 Oct 2020 23:02:49 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4C9Q201TV1z8tZH; Tue, 13 Oct 2020 08:02:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602568968; bh=KvWWrTHBQkjbKsr+Xit46gY3DkjCn0zgLtu/cOn2uSg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=nWbAbkw85fBWq0vEZ7+qyJ9ALi0+heEaIMKEBPoB10Vas/8lMZfgRubPVTFtsWiVd 6mqUPpPAuB8x8g2sPZ0z6t+PEzQ0oCTc789HCDM3yjqrtL8Ea/OuQLzkhb7m4dVzjM VOP/c6Dm2Jrw+3WyGHeZn4OqmGG154fgs9HaRoHHPyYRwM1F4e/tW1KwuatPfvTT4Z eqggJ5OpeNFH7NZ/1VZpOB3Z5/Zv7ybuG5X+4BZlP0JMnX7gYOuM3ITw8xYsRi2rUW Mj+BGPT0zAo+pVwq1MdbLXNCLLh0ihi52dnwtw4Z0oi/X2tOdORlsuZMz38yXW1nCA XrZb19E6dwe8Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4C9Q2008RPzCqlQ; Tue, 13 Oct 2020 08:02:48 +0200 (CEST) From: To: Nagendra Nainar , "ops-dir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-dots-server-discovery.all@ietf.org" , "dots@ietf.org" Thread-Topic: [Last-Call] Opsdir last call review of draft-ietf-dots-server-discovery-11 Thread-Index: AQHWoPNmnXuKWD69u0iulfhJ4MHaP6mVAuDQ Date: Tue, 13 Oct 2020 06:02:47 +0000 Message-ID: <28519_1602568968_5F854308_28519_463_1_787AE7BB302AE849A7480A190F8B93303155F186@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160254645915.19164.9668371473019350974@ietfa.amsl.com> In-Reply-To: <160254645915.19164.9668371473019350974@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] [Last-Call] Opsdir last call review of draft-ietf-dots-server-discovery-11 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, 13 Oct 2020 06:02:52 -0000 Hi Nagendra,=20 Thank you for the review.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: last-call [mailto:last-call-bounces@ietf.org] De la part de > Nagendra Nainar via Datatracker > Envoy=E9=A0: mardi 13 octobre 2020 01:48 > =C0=A0: ops-dir@ietf.org > Cc=A0: last-call@ietf.org; draft-ietf-dots-server- > discovery.all@ietf.org; dots@ietf.org > Objet=A0: [Last-Call] Opsdir last call review of draft-ietf-dots- > server-discovery-11 >=20 > Reviewer: Nagendra Nainar > Review result: Has Nits >=20 > Hi, >=20 > I have reviewed this document as part of the Operational > directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the intent > of improving the operational aspects of the IETF drafts per > guidelines in RFC5706. >=20 > Comments that are not addressed in last call may be included in AD > reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. >=20 > Version: draft-ietf-dots-server-discovery-11 >=20 > Overall Summary: >=20 > This draft is a standard track proposing the DOTS server discovery > procedure. > The draft proposes 3 different discovery options and sufficiently > clarify the procedure required when one or more of the options co- > exist. The draft further defines the protocol extensions required to > carry the details in DHCPv4, DHCPv6 options and for DNS service > discovery. >=20 > Overall this is a well written document. Some ambiguity observed > that needs attention are listed below: >=20 > --> Section 5 states the below: > " > The list of the IP addresses returned by DHCP servers is > typically > used to feed the DOTS server selection procedure or to provide > DOTS > agents with primary and backup IP addresses of their peer DOTS > agents." >=20 > While the DHCP options replies with the bunch of IP/Ipv6 address of > the peer DOTS agents. Is there any mechanism specified (or required) > to select the primary/backup?. Or is it a local matter?. [Med] This is beyond discovery and is handled by the DOTS agent itself. See= for example, https://tools.ietf.org/html/rfc8782#section-4.3.=20 >=20 > =3D=3D> The below text suggest to discard multicast and loopback > address. While it is obvious for global scoped address, how would > the node behave if it receives other reserved range address (such as > Discard)?. Can it accept link-local address?. [Med] link-local addresses are acceptable. Think about an internal DOTS cli= ent in a LAN and a DOTS gateway in the CPE.=20=20 Entities operating a DOTS server are supposed to be familiar with RFC6666 (= discard). No specific behaviour is required at the client side. Packets sen= t to such address are likely to be blocked (if the client and the server ar= e located in the distinct domains) or be subject to any policy at the DOTS = server domain.=20 >=20 > The DHCP client MUST silently discard multicast and host loopback > addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. >=20 > =3D=3D> It will be good if you can name the tables. [Med] OK. >=20 > Few observations below: >=20 > s/Districuted/Distributed [Med] Thanks. >=20 > Thanks, > Nagendra >=20 >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Oct 12 23:29: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 A87343A0E7E; Mon, 12 Oct 2020 23:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-DyLaz_PcRP; Mon, 12 Oct 2020 23:29:36 -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 112B13A0E7D; Mon, 12 Oct 2020 23:29:36 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4C9Qct3JJqz8tlv; Tue, 13 Oct 2020 08:29:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602570574; bh=U4CWAozpUgMophUDACFwJ+GM09B0DM78ENGb/pJu+tk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ZiSQisFOLEvXcCHlGjQQ/3CgquP+6zLz+dQZAePcHUmdXtvQcad11zgJDuQurwsIy SaC3FS1orhUKDmWbwTLZz3jEQBdQJL+SUNL/XNCTCPbOAh70VYw0WbWKKJMUpZoXXp 6YvGHeX9mbqCk4sNLvwPl/3MXhp/MQHVuNRPnVzHdPcBcIZqj5J6LPW0jOLbDs9H9e 05ReytJotKfP8y5aNN/KoI6oiI7eTfiWcrL984p95asDmhndoEqk1xXuNn8DgzKYoJ ouQ4OxS2YTYjkVprTPLNnraMbNNNR+KjGOG5d5G/YGlZeABcxKtzzLDUWy0pOBjcgw 4QLnsRjiS4p2A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4C9Qct22Pgz1xpX; Tue, 13 Oct 2020 08:29:34 +0200 (CEST) From: To: Zhen Cao , "int-dir@ietf.org" CC: "draft-ietf-dots-server-discovery.all@ietf.org" , "last-call@ietf.org" , "dots@ietf.org" Thread-Topic: Intdir last call partial review of draft-ietf-dots-server-discovery-11 Thread-Index: AQHWoKeFIGPePct4Y0yQ8+mIUeZiuKmVDuOQ Date: Tue, 13 Oct 2020 06:29:33 +0000 Message-ID: <31047_1602570574_5F85494E_31047_384_1_787AE7BB302AE849A7480A190F8B93303155F1B2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160251443866.28127.2696320816235439108@ietfa.amsl.com> In-Reply-To: <160251443866.28127.2696320816235439108@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Intdir last call partial review of draft-ietf-dots-server-discovery-11 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, 13 Oct 2020 06:29:38 -0000 SGkgWmhlbiwgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gDQoNClBsZWFzZSBzZWUgaW5s aW5lLg0KDQpDaGVlcnMsDQpNZWQgDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IFpoZW4gQ2FvIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmdd DQo+IEVudm95w6nCoDogbHVuZGkgMTIgb2N0b2JyZSAyMDIwIDE2OjU0DQo+IMOAwqA6IGludC1k aXJAaWV0Zi5vcmcNCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci1kaXNjb3ZlcnkuYWxs QGlldGYub3JnOyBsYXN0LQ0KPiBjYWxsQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IE9iamV0 wqA6IEludGRpciBsYXN0IGNhbGwgcGFydGlhbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLXNl cnZlci0NCj4gZGlzY292ZXJ5LTExDQo+IA0KPiANCj4gUmV2aWV3IGlzIHBhcnRpYWxseSBkb25l LiBBbm90aGVyIGFzc2lnbm1lbnQgbWF5IGJlIG5lZWRlZCB0bw0KPiBjb21wbGV0ZSBpdC4NCj4g DQo+IFJldmlld2VyOiBaaGVuIENhbw0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHMN Cj4gDQo+IFJldmlld2VyOiBaaGVuIENhbw0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5p dHMNCj4gDQo+IFRoYW5rcyB0aGUgYXV0aG9ycyBmb3IgdGhlIGRvY3VtZW50LiAgRE9UUyBzZXJ2 ZXIgZGlzY292ZXJ5IGlzDQo+IGltcG9ydGFudCB0byB0aGUgZnVuY3Rpb25pbmcgb2YgdGhlIHdo b2xlIHN5c3RlbS4NCj4gDQo+IEltcG9ydGFudDogSSByZWFkIEJlcm5pZSdzIGVhcnkgcXVpY2sg cmV2aWV3IChzYXlpbmcgbm90IGEgZnVsbCBvbmUpDQo+IGZvciB0aGUgMDENCj4gdmVyc2lvbiBb Kl0gYW5kIHRoZSBjb21tZW50cyBoYWQgYmVlbiBhZGRyZXNzZWQgaW4gMDIgdmVyc2lvbi4gICBB bmQNCj4gSSB0aGluaw0KPiBvdXIgQUQgQEVyaWMgbmVlZHMgdG8gY2hlY2sgaWYgdGhlcmUgaXMg YSBuZWVkIGZvciBmdXJ0aGVyIERIQw0KPiBkb2N0b3IgcmV2aWV3Lg0KPiAgKGFsdGhvdWdoIEkg Y2hlY2tlZCB0aGVyZSB3ZXJlIG5vdCBtdWNoIGNoYW5nZWQgb24gdGhlIERIQ1AgcGFydHMNCj4g ZnJvbSByMDIgdG8NCj4gcjExKSAuDQo+IA0KPiBbKl1odHRwczovL2dpdGh1Yi5jb20vYm91Y2Fk YWlyL2RyYWZ0LWlldGYtZG90cy1kaXNjb3ZlcnkvaXNzdWVzLzENCj4gDQo+IEkgdGhpbmsgbW9z dCBvZiB0aGUgb3RoZXIgcGFydHMgbG9va3MgcXVpdGUgcmVhZHkgZXhjZXB0Og0KPiBhKSBTZWN0 aW9uIDUuMS4yIG9uIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBpcHY0LW1hcHBlZCBJUHY2DQo+ IGFkZHJlc3MuDQo+IG9sZDogICAgTm90ZSwgSVB2NC1tYXBwZWQgSVB2NiBhZGRyZXNzZXMgKFNl Y3Rpb24gMi41LjUuMiBvZg0KPiBbUkZDNDI5MV0pICBhcmUNCj4gYWxsb3dlZCB0byBiZSBpbmNs dWRlZCBpbiB0aGlzIG9wdGlvbi4NCj4gDQo+IEkgZG8gbm90IGtub3cgd2h5IHRoaXMgaXMgcGFy dGljdWxhcmx5IG1lbnRpb25lZCBoZXJlIGdpdmVuIHRoZXJlDQo+IGFyZSBtYW55IHR5cGVzIG9m IElQdjYgYWRkcmVzcy4gDQoNCltNZWRdIEFzIHlvdSBjYW4gcmVhZCBmb3IgZXhhbXBsZSBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjA1MiNzZWN0aW9uLTQuMiBvciBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjcyNCNzZWN0aW9uLTMuMiwgdGhlc2UgYWRkcmVzc2Vz IGFyZSBoYW5kbGVkIGFzIElQdjQgb25lcy4gVGhpcyB3b3VsZCBhbGxvdyB0byB1c2UgREhDUHY2 IHRvIGNvbW11bmljYXRlIGJvdGggSVB2NiBhbmQgSVB2NCBhZGRyZXNzZXMgdG8gcmVhY2ggYSBk dWFsLXN0YWNrIERPVFMgYWdlbnQuICAgIA0KDQogSSB0aGluayBpdCAncyBiZXR0ZXIgdG8gcmVt b3ZlIHRoaXMNCj4gc3RhdGVtZW50IHNpbmNlIHRoZXJlIGFyZSBtYW55IGlzc3VlcyBjb25maWd1 cmluZyBJUHY0LW1hcHBlZA0KPiBhZGRyZXNzIGRpcmVjdGx5LiAgU29tZSBzeXN0ZW1zIHdpbGwg ZGlzYWJsZSAoYnkgZGVmYXVsdCkgc3VwcG9ydA0KPiBmb3IgaW50ZXJuYWwgIElQdjQtbWFwcGVk IElQdjYgYWRkcmVzc2VzLg0KDQpbTWVkXSBUaGUgaW50ZW50IG9mIHRoZSBzZW50ZW5jZSB5b3Ug cXVvdGVkIGlzIHRvIGF2b2lkIHN1Y2ggYmVoYXZpb3JzIGFuZCBhbGxvdyB0byB1c2Ugc3VjaCBh ZGRyZXNzZXMgYXMgcGVyIHRoZSBSRkNzIGxpc3RlZCBhYm92ZS4gDQoNCj4gU29tZSBpbXBsZW1l bnRhdGlvbnMgb2YgZHVhbC1zdGFjayBkbyBub3QgYWxsb3cgSVB2NC1tYXBwZWQgSVB2Ng0KPiBh ZGRyZXNzZXMgdG8gYmUgdXNlZCBmb3IgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIElQdjQgYW5k IElQdjYNCj4gYXBwbGljYXRpb25zLiAgW1JGQzQwMzhdLg0KPiBTdWNoIGRpc2N1c3Npb25zIGRv IG5vdCBoYXZlIHRvIGJlIHByZXNlbnQgaGVyZS4NCj4gDQo+IGIpIHRoZSBmaXJzdCBzZW50ZW5j ZSBvZiB0aGUgYWJzdHJhY3Q6IHMvRGlzdHJpY3V0ZWQvRGlzdHJpYnV0ZWQuDQo+IA0KDQpbTWVk XSBGaXhlZC4gVGhhbmtzLiANCg0KPiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Oct 13 01:29: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 DE7133A091A; Tue, 13 Oct 2020 01:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grZyiYJz3cmG; Tue, 13 Oct 2020 01:28:54 -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 377CB3A0658; Tue, 13 Oct 2020 01:28:54 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4C9TGW5Cfbz8xJg; Tue, 13 Oct 2020 10:28:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602577731; bh=LQgQK9RX+xAwUxhUCzwH8xV1pApc+nvor2Nb6up0fm8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=l1swzeXjBPvlDS/pA0SMAATMRrIdtLneUllUuWPEiivaRoA1ZqANEGjgQCC5QQ3SZ mMd8Jm87fHHkv60aoZab9kN1hY2dWnoJkyuHCbtOcA7jNCAm+j2aB1TEX9UMNCuAbI f77mrR/+2KdX1kRUwCerbQdlLYiGo0Urnx6JOd0j9y8EsKF96PD32SWKM5BwU/fLVF +Y6d/haLEwZux5JOkV/8hgFNoz2qZC3bkKIpsb0if/6Ssex2R7mxYCpBAfx6Ek0iin alZ0yArjDydgmY4Sf2EioxbOO4nTN9kfQ2uUFyFXqQItELAqCM0ZJaNy6U1aWRNFsw YFJomDSrbkwmQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4C9TGW3rSWz2xCg; Tue, 13 Oct 2020 10:28:51 +0200 (CEST) From: To: Kyle Rose , "tsv-art@ietf.org" CC: "last-call@ietf.org" , "dots@ietf.org" , "draft-ietf-dots-server-discovery.all@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-dots-server-discovery-11 Thread-Index: AQHWoCv6EYbxylq39kqMV/uafG6Ik6mVFVTg Date: Tue, 13 Oct 2020 08:28:51 +0000 Message-ID: <22178_1602577731_5F856543_22178_325_7_787AE7BB302AE849A7480A190F8B93303155F274@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160246137613.594.10649805135544482452@ietfa.amsl.com> In-Reply-To: <160246137613.594.10649805135544482452@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-server-discovery-11 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, 13 Oct 2020 08:28:56 -0000 SGkgS3lsZSwgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4NCg0KUGxlYXNlIHNlZSBpbmxp bmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4g RGXCoDogS3lsZSBSb3NlIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmdd DQo+IEVudm95w6nCoDogbHVuZGkgMTIgb2N0b2JyZSAyMDIwIDAyOjEwDQo+IMOAwqA6IHRzdi1h cnRAaWV0Zi5vcmcNCj4gQ2PCoDogbGFzdC1jYWxsQGlldGYub3JnOyBkb3RzQGlldGYub3JnOyBk cmFmdC1pZXRmLWRvdHMtc2VydmVyLQ0KPiBkaXNjb3ZlcnkuYWxsQGlldGYub3JnDQo+IE9iamV0 wqA6IFRzdmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1zZXJ2ZXItZGlz Y292ZXJ5LQ0KPiAxMQ0KPiANCj4gUmV2aWV3ZXI6IEt5bGUgUm9zZQ0KPiBSZXZpZXcgcmVzdWx0 OiBSZWFkeSB3aXRoIElzc3Vlcw0KPiANCj4gVGhpcyBkb2N1bWVudCBoYXMgYmVlbiByZXZpZXdl ZCBhcyBwYXJ0IG9mIHRoZSB0cmFuc3BvcnQgYXJlYSByZXZpZXcNCj4gdGVhbSdzIG9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBrZXkgSUVURiBkb2N1bWVudHMuIFRoZXNlIGNvbW1lbnRzDQo+IHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1 dCBhcmUNCj4gY29waWVkIHRvIHRoZSBkb2N1bWVudCdzIGF1dGhvcnMgYW5kIFdHIHRvIGFsbG93 IHRoZW0gdG8gYWRkcmVzcyBhbnkNCj4gaXNzdWVzIHJhaXNlZCBhbmQgYWxzbyB0byB0aGUgSUVU RiBkaXNjdXNzaW9uIGxpc3QgZm9yIGluZm9ybWF0aW9uLg0KPiANCj4gV2hlbiBkb25lIGF0IHRo ZSB0aW1lIG9mIElFVEYgTGFzdCBDYWxsLCB0aGUgYXV0aG9ycyBzaG91bGQgY29uc2lkZXINCj4g dGhpcyByZXZpZXcgYXMgcGFydCBvZiB0aGUgbGFzdC1jYWxsIGNvbW1lbnRzIHRoZXkgcmVjZWl2 ZS4gUGxlYXNlDQo+IGFsd2F5cyBDQyB0c3YtYXJ0QGlldGYub3JnIGlmIHlvdSByZXBseSB0byBv ciBmb3J3YXJkIHRoaXMgcmV2aWV3Lg0KPiANCj4gPkZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRo ZSB0cmFuc3BvcnQgYXJlYSwgdGhpcyBkb2N1bWVudCBpcyBSZWFkeToNCj4gdGhlDQo+IHNwZWNp ZmljYXRpb24gb2YgbmV3IFNSViBhcHBsaWNhdGlvbiBwcm90b2NvbCBuYW1lcyBhcHBlYXJzIHRv DQo+IGNvbXBseSB3aXRoIGN1cnJlbnQgVFNWQVJUIGd1aWRhbmNlLg0KPiANCg0KW01lZF0gVGhh bmtzLiANCg0KPiBUaGF0IHNhaWQsIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMg dGhhdCBtYXkgb3IgbWF5IG5vdCBiZQ0KPiBvZiBpbnRlcmVzdCB0byB0aGUgdHJhbnNwb3J0IEFE czoNCj4gDQo+ICogU2VjdGlvbiA0IHNheXM6DQo+IA0KPiAgICBUaGUgZGlzY292ZXJ5IG1ldGhv ZCBpcyByZWl0ZXJhdGVkIGJ5IGEgRE9UUyBhZ2VudCB1cG9uIHRoZQ0KPiBmb2xsb3dpbmcNCj4g ICAgZXZlbnRzOg0KPiANCj4gICAgbyAgRXhwaXJ5IG9mIGEgYSB2YWxpZGl0eSB0aW1lciAoZS5n LiwgREhDUCBsZWFzZSwgRE5TIFRUTCkNCj4gICAgICAgYXNzb2NpYXRlZCB3aXRoIGEgZGlzY292 ZXJlZCBET1RTIGFnZW50Lg0KPiANCj4gPkZyb20gbXkgcmVhZGluZywgcmVuZGV6dm91cyBpbmZv cm1hdGlvbiBmb3IgdGhlIERPVFMgc2VydmVyIGlzDQo+ICJwdXNoZWQiDQo+ID50byB0aGUNCj4g Y2xpZW50IHZpYSBESENQLCBzbyBpdCdzIG5vdCBjbGVhciB0aGUgYWJvdmUgaXMgYWN0aW9uYWJs ZS4gSXMgaXQNCj4gc2ltcGx5IHRoZSBjYXNlIHRoYXQgYSBjbGllbnQgc2hvdWxkIHVzZSB0aGUg RE9UUyBzZXJ2ZXIgYXNzaWduZWQgaW4NCj4gdGhlIG1vc3QgcmVjZW50IGxlYXNlPw0KPiANCg0K W01lZF0gVGhlIGludGVudCBpcyB0byBhdm9pZCB1c2luZyAic3RhbGUiIHNlcnZlcnMuIFNvIHll cywgdGhpcyBpcyBhYm91dCB1c2luZyB0aGUgc2VydmVyIHRoYXQgd2FzIG1vc3QgcmVjZW50bHkg ZGlzY292ZXJlZCBidXQgYWxzbyBhYm91dCBub3QgdXNpbmcgYSBzZXJ2ZXIgYmV5b25kIGEgdmFs aWRpdHkgdGltZSBhc3NvY2lhdGVkIHdpdGggdGhlIGRpc2NvdmVyZWQgc2VydmVyLiANCg0KPiAq IFNlY3Rpb24gNS4xIGRlc2NyaWJlcyBhIHRydXN0IG1lY2hhbmlzbSB0aGF0IGNhbiBjaGFyaXRh Ymx5IGJlDQo+IGRlc2NyaWJlZCBhcyAiaG9wZWZ1bCIuIEZ1bmRhbWVudGFsbHksIHRoZSBzZWN1 cml0eSBvZiBUTFMgcmVsaWVzIG9uDQo+IGEgdGhyZWUtbGVnZ2VkIHN0b29sOg0KPiANCj4gICAg ICgxKSBUaGUgaW50ZWdyaXR5IG9mIHRoZSBYLjUwOSBzZXJ2ZXIgY2VydGlmaWNhdGUgaXNzdWFu Y2UNCj4gcHJvY2VkdXJlcw0KPiAgICAgKDIpIFRoZSBjcnlwdG9ncmFwaGljIHRydXN0IGFuY2hv cnMgY29uZmlndXJlZCBpbiBhIGNsaWVudA0KPiAgICAgKDMpIFByZS1lc3RhYmxpc2hlZCB0cnVz dCBpbiB0aGUgc2VydmVyJ3MgaWRlbnRpdHksIHdoaWNoIG11c3QNCj4gbWF0Y2ggYQ0KPiAgICAg U2VydmVyQWx0TmFtZSBpbiB0aGUgc2lnbmVkIHNlcnZlciBjZXJ0aWZpY2F0ZQ0KPiANCj4gVGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYnJpZWZseSBhbGx1ZGVzIHRvIHRoZSBw cm9ibGVtcw0KPiB3aXRoIHVzaW5nIERIQ1AgdmlhIHJlZmVyZW5jZSB0byBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9ucyBpbg0KPiBESENQIFJGQ3MsIGJ1dCBJIGRvbid0IHRoaW5rIHRo YXQgcXVpdGUgZG9lcyBqdXN0aWNlIHRvIHRoZSBwcm9ibGVtDQo+IGhlcmUuIFRMUyBpcyBjcmlw cGVkIGJ5IGEgZmFpbHVyZSBpbiBhbnkgb2YgdGhlIGFib3ZlOg0KPiANCj4gICAgICogQSB0cnVz dGVkIENBIHdyb25nbHkgaXNzdWVzIGEgY2VydGlmaWNhdGUgdG8gYSB0aGlyZCBwYXJ0eQ0KPiB3 aXRoIHRoZQ0KPiAgICAgYWJpbGl0eSB0byBoaWphY2sgcmVuZGV6dm91cyAoZS5nLiwgdGhyb3Vn aCBCR1Agb3IgRE5TIGF0dGFja3MpDQo+ICogQSB1c2VyJ3MNCj4gICAgIGNlcnRpZmljYXRlIHN0 b3JlIGlzIGF1Z21lbnRlZCBieSBhIENBIHVuZGVyIHRoZSBjb250cm9sIG9mIGFuDQo+IGFkdmVy c2FyeSAqDQo+ICAgICBWaWEgYSBtaXN0YWtlbiBvciBpbmplY3RlZCBob3N0bmFtZSwgYSB1c2Vy IGVzdGFibGlzaGVzIGENCj4gY29ubmVjdGlvbiB0byB0aGUNCj4gICAgIHdyb25nIGVuZHBvaW50 IHRoYXQgbm9uZXRoZWxlc3MgaGFzIGEgbGVnaXRpbWF0ZWx5LWlzc3VlZA0KPiBjZXJ0aWZpY2F0 ZQ0KPiANCj4gVXNpbmcgREhDUCwgYW4gaW5oZXJlbnRseSBpbnNlY3VyZSBwcm90b2NvbCwgdG8g aW5mb3JtIERPVFMgY2xpZW50cw0KPiBvZiB0aGUgaG9zdG5hbWUgb2YgRE9UUyBzZXJ2ZXIga25v Y2tzIHRoaXMgdGhpcmQgbGVnIG91dCwgY2FsbGluZw0KPiBpbnRvIHF1ZXN0aW9uIHRoZSBlbnRp cmUgbWVjaGFuaXNtLg0KDQpbTWVkXSBXZSBkaWRuJ3QgaW5jbHVkZSBzdWNoIGRpc2N1c3Npb24g YXMgdGhpcyBpcyBhIHZhcmlhdGlvbiBvZiBhZ2VudCBpbXBlcnNvbmF0aW9uIChjb3ZlcmVkIGJ5 IHRoZSBwb2ludGVyIHRvIFJGQzg4MTEpIGFuZCByb2d1ZSBzZXJ2ZXJzIGluIFJGQzg0MTUuIEFs c28sIHdlIGhhdmUgdGhlIGZvbGxvd2luZzoNCg0KICAgVGhpcyBkb2N1bWVudCBhc3N1bWVzIHRo YXQgc2VjdXJpdHkgY3JlZGVudGlhbHMgdG8gYXV0aGVudGljYXRlIERPVFMNCiAgIHNlcnZlcihz KSBhcmUgcHJvdmlzaW9uZWQgdG8gYSBET1RTIGNsaWVudCB1c2luZyBhIG1lY2hhbmlzbSBzdWNo IGFzDQogICAoYnV0IG5vdCBsaW1pdGVkIHRvKSB0aG9zZSBkaXNjdXNzZWQgaW4gW1JGQzg1NzJd IC4uLg0KDQpXZSBjYW4gYWRkIHNvbWUgdGV4dCB0byBlbGFib3JhdGUgb24gdGhpcyBmdXJ0aGVy LiANCg0KIE1lYXN1cmVzIGNhbiBiZSB0YWtlbiB0bw0KPiBtaXRpZ2F0ZSB0aGlzIHJpc2ssIHN1 Y2ggYXMgY29uZmlndXJpbmcgY2xpZW50cyB3aXRoIGEgZG9tYWluDQo+IHdoaXRlbGlzdCAoZS5n LiwgYWNjZXB0IERPVFMgbmFtZXMgb25seSB3aXRoaW4gYSBwYXJ0aWN1bGFyIGRvbWFpbiksDQo+ IGNvbmZpZ3VyaW5nIGNsaWVudHMgd2l0aCBhIHNldCBvZiBwcml2YXRlIENBcyBhcyB0cnVzdCBh bmNob3JzLA0KPiBjb25maWd1cmluZyBib3JkZXIgcm91dGVycyB3aXRoIG5ldHdvcmstbGF5ZXIg cGFja2V0IGZpbHRlcmluZyBmb3INCj4gRE9UUyB0cmFmZmljLCBldGMuLCBidXQgdWx0aW1hdGVs eSB3aXRob3V0IHNvbWUgcHJlY29uZmlndXJhdGlvbiwNCj4gY2xpZW50cyBhcmUgYXQgdGhlIG1l cmN5IG9mIHJvZ3VlIERIQ1AuDQo+IA0KPiAqIFNlY3Rpb24gNS4yLjEgaGFzOg0KPiANCj4gICAg VGhlIERIQ1B2NCBbUkZDMjEzMl0gRE9UUyBSZWZlcmVuY2UgSWRlbnRpZmllciBvcHRpb24gaXMg dXNlZCB0bw0KPiAgICBjb25maWd1cmUgYSBuYW1lIG9mIHRoZSBwZWVyIERPVFMgYWdlbnQuICBU aGUgZm9ybWF0IG9mIHRoaXMNCj4gb3B0aW9uDQo+ICAgIGlzIGlsbHVzdHJhdGVkIGluIEZpZ3Vy ZSA2Lg0KPiANCj4gICAgICAgICAgICAgQ29kZSAgTGVuZ3RoICAgUGVlciBET1RTIGFnZW50IG5h bWUNCj4gICAgICAgICAgICArLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0t LS0rLS0NCj4gICAgICAgICAgICB8VEJBMyB8ICBuICB8ICBzMSB8ICBzMiB8ICBzMyB8ICBzNCB8 IHM1ICB8ICAuLi4NCj4gICAgICAgICAgICArLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0r LS0tLS0rLS0tLS0rLS0NCj4gDQo+ICAgICAgVGhlIHZhbHVlcyBzMSwgczIsIHMzLCBldGMuIHJl cHJlc2VudCB0aGUgZG9tYWluIG5hbWUgbGFiZWxzIGluDQo+IHRoZQ0KPiAgICAgIGRvbWFpbiBu YW1lIGVuY29kaW5nLg0KPiANCj4gSXMgdGhlIGZpbmFsIGxhYmVsIHplcm8tbGVuZ3RoPw0KDQpb TWVkXSBZZXMsIGFzIGluZGljYXRlZCBpbiA1LjIuMTogDQoNCiAgIG8gIFBlZXIgRE9UUyBhZ2Vu dCBuYW1lOiBUaGUgZG9tYWluIG5hbWUgb2YgdGhlIHBlZXIgRE9UUyBhZ2VudC4NCiAgICAgIFRo aXMgZmllbGQgaXMgZm9ybWF0dGVkIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDEwIG9mIFtSRkM4 NDE1XS4gDQoNCiBPdGhlciBwYXJ0cyBvZiB0aGUgREhDUHY0IHByb3RvY29sDQo+IHRlcm1pbmF0 ZSBkb21haW4gbmFtZXMgd2l0aCBhIHplcm8tbGVuZ3RoIGxhYmVsLiBXaGF0IGlmIGEgemVyby0N Cj4gbGVuZ3RoIGxhYmVsIGFwcGVhcnMgaW4gc29tZSBzX2kgb3RoZXIgdGhhbiB0aGUgZmluYWwg b25lPw0KPiANCg0KW01lZF0gTmFtZXMgYXJlIHZhbGlkYXRlZCBhcyBwZXIgdGhlIHJ1bGVzIGlu IFNlY3Rpb24gMTAgb2YgUkZDODQxNTogIA0KDQogICBJZiB0aGUgREhDUCBjbGllbnQgcmVjZWl2 ZXMgT1BUSU9OX1Y0X0RPVFNfUkkgb25seSwgYnV0DQogICBPUFRJT05fVjRfRE9UU19SSSBvcHRp b24gY29udGFpbnMgbW9yZSB0aGFuIG9uZSBuYW1lLCBhcw0KICAgZGlzdGluZ3Vpc2hlZCBieSB0 aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgcm9vdCBsYWJlbHMsIHRoZSBESENQDQogICBjbGllbnQg TVVTVCB1c2Ugb25seSB0aGUgZmlyc3QgbmFtZS4gIE9uY2UgdGhlIG5hbWUgaXMgdmFsaWRhdGVk DQogICAoU2VjdGlvbiAxMCBvZiBbUkZDODQxNV0pLCB0aGUgbmFtZSBpcyBwYXNzZWQgdG8gYSBu YW1lIHJlc29sdXRpb24NCiAgIGxpYnJhcnkuDQoNCj4gKiBTZWN0aW9uIDcgc2F5czoNCj4gDQo+ ICAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGFueSBrZXlzOyB0aGUgVFhUIHJlY29y ZCBvZiBhIEROUy0NCj4gU0QNCj4gICAgc2VydmljZSBpcyB0aHVzIGVtcHR5IChTZWN0aW9uIDYg b2YgW1JGQzY3NjNdKS4NCj4gDQo+IFJGQyA2NzYzIHNheXMgdGhhdCBhbiBlbXB0eSBUWFQgcmVj b3JkIE1VU1QgYmUgaW5jbHVkZWQgYWxvbmdzaWRlDQo+IHRoZSBTUlYgcmVjb3JkIHdoZXJlIERO Uy1TRCBpcyBjb25jZXJuZWQuIFNob3VsZCBub3JtYXRpdmUgbGFuZ3VhZ2UNCj4gYmUgdXNlZCBo ZXJlLCBvciBzaG91bGQgd2UgcmVseSBvbiB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZSBpbiBjYXNl DQo+IHRoYXQgZ3VpZGFuY2UgY2hhbmdlcyBpbiB0aGUgZnV0dXJlPw0KDQpbTWVkXSBJIGRvbid0 IHRoaW5rIHRoYXQgdGhlIHVzZSBvZiBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbmVlZGVkIGhlcmUu IFJGQzY3NjMgaXMgc3VmZmljaWVudCBieSBpdHMgb3duLg0KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Oct 13 07:59:54 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 9EEA83A09AC; Tue, 13 Oct 2020 07:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160260118560.11110.4639202476035646156@ietfa.amsl.com> Date: Tue, 13 Oct 2020 07:59:45 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-12.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, 13 Oct 2020 14:59:52 -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) Agent Discovery Authors : Mohamed Boucadair Tirumaleswar Reddy Filename : draft-ietf-dots-server-discovery-12.txt Pages : 26 Date : 2020-10-13 Abstract: This document specifies mechanisms to configure Distributed Denial of Service Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. Knowing the appropriate DOTS server for a given location can be useful to engage mitigation actions even in cases where the DOTS client cannot localize the attack, but only knows that some resources are under attack and that help is needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-server-discovery-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-12 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 Oct 13 16:08: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 6EF2D3A11FA; Tue, 13 Oct 2020 16:08:31 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 eyLdP1OUnmyy; Tue, 13 Oct 2020 16:08:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E9A593A11F9; Tue, 13 Oct 2020 16:08:27 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09DN8KPn027189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Oct 2020 19:08:24 -0400 Date: Tue, 13 Oct 2020 16:08:19 -0700 From: Benjamin Kaduk To: draft-ietf-dots-signal-call-home.all@ietf.org Cc: dots@ietf.org Message-ID: <20201013230819.GA50845@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 23:08:32 -0000 Hi all, Nothing super-earth-shattering in here, but there's enough that we'll need a revised I-D and some more WG input before I'm ready to start the IETF LC. -Ben YANG lint says: ietf-dots-call-home@2020-07-07.yang:11: warning: imported module "ietf-dots-signal-channel" not used AFAICT that's a yanglint bug, since we do augment nodes from the signal channel. I see that this document has a few IPR notices against it; in particular, the one at https://datatracker.ietf.org/ipr/3318/ does not list any licensing terms ("Unwilling to Commit to the Provisions of a), b), or c) Above", where a/b/c are "no license needed for implementation"/"RAND with no fee"/"RAND with possible fee"). I believe we are working to see if the situation can be clarified and the IPR disclosure updated, but I don't know that we need to delay any progress until that has occurred. That said, personally, I'm not very comfortable about a protocol that potentially is encumbered by IPR with unknown license terms. However, I am willing to at least advance the document to IETF LC if there is clear WG support for doing so, even knowing that use of the protocol would potentially be subject to arbitrary terms from the IPR holder. I would really like to hear from the WG members on this point. I mention it in the section-by-section comments, but we introduce the possibility of "wait for administrator approval" in the mitigation-request processing pipeline, which could exceed a normal CoAP request timeout. I think we need to have some substantive text discussion the expected behavior in this case. Section 1.1 Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, and Transport Layer Security (TLS) re-negotiation are difficult to detect on a home network device without adversely affecting its (side note) TLS renegotiation as an attack is just keeping a TLS connection open and repeatedly re-negotiating to cause the server to burn CPU on signing operations? I don't think I've heard of that one before. Section 1.2 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers to a DOTS signal channel established at the initiative of a DOTS server. That is, the DOTS server initiates a secure connection to a DOTS client, and uses that connection to receive the attack traffic information (e.g., attack sources) from the DOTS client. More details are provided in Section 3. I think this introductory section needs to be crystal clear for the reader about the relationship between the "conventional" signal channel DOTS client and the corresponding call home DOTS client for a given mitigation process. Some people will expect both things with "client" in the name to be on the same device, and some people will expect the (call home) client to be the device that makes mitigation requests, but both cannot be right. The phrase "role reversal" might be useful in describing these interpretations, as might a forward reference to section 1.4. (Yes, I understand that there is no need for either DOTS call home peer to be colocated with any base signal channel element, but I think that the default scenario in many readers' minds will be the simple role-reversal setup.) Section 1.3 It's a little unfortunate that we are using the "DMS" acronym in the figure here, when we only mention the terminology of RFC 8612 in section 2. (That said, I'm willing to leave it as-is for now and see if anyone complains.) Section 3.1 The DOTS signal channel Call Home preserves all but one of the DOTS client/server roles in the DOTS protocol stack, as compared to DOTS client-initiated DOTS signal channel protocol I suppose one could quibble about whether "party allowed to behave passively with respect to heartbeats" qualifies as a "client/server role" ... I think I'm okay leaving this as-is for now, though. For example, a home network element (e.g., home router) co-located with a Call Home DOTS server is the (D)TLS server. However, when Figure 7 has a box labelled "Call Home DOTS server" and also "(D)TLS client" (not server). At first I thought this was trying to make an analogy to a (normal) signal channel DOTS server as being the (D)TLS server, but that would not be in a home network element. So maybe this is just a typo? calling home, the DOTS server initially assumes the role of the (D)TLS client, but the network element's role as a DOTS server We may want to continue using "DOTS Call Home server" in these two lines. remains the same. Furthermore, existing certificate chains and mutual authentication mechanisms between the DOTS agents are unaffected by the Call Home function. This Call Home function This may merit a bit more text, or at least a bit more thought, since we are now asking the certificate validation to be used for a different logical purpose. While it's true that the entity acting as a (D)TLS server is likely to be the same device as a regular DOTS server (or at least operated by the same DMS provider), and so there is a fairly strong analogue there in terms of the (D)TLS server certificate validation procedures, the (D)TLS client is something of a different entity than a traditional DOTS client. It's true that RFC 8782 leaves the specifics of the mutual authentication a bit under-specified (and essentially just says that it has to happen somehow), but one might imagine that the number of DOTS clients are fairly small and tied to specific legal contracts, so manual provisioning (or provisioning during onboarding) of client certificate information is reasonable. For the call home case, we should expect a lot more call home DOTS servers (i.e., (D)TLS clients) and thus should probably have a better story for automating the mutual authentication check. Defining an extendedKeyUsage value that indicate authorization to act as a call home server would be one typical way to do so (it's perhaps unfortunate that we didn't define an EKU for DOTS client usage), but if we're not going to do that we should at least put some words in about how the mutual authentication requirement remains but a different ACL may be needed for call home than for traditional DOTS sessions. enables the DOTS server co-located with a network element (possibly (Still Call Home server, right?) Section 3.2.1 If the Call Home DOTS server does not receive any traffic from the peer Call Home DOTS client during the time span required to exhaust the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server concludes the session is disconnected. Then, the Call Home DOTS server MUST try to resume the (D)TLS session. Why resume specifically, as opposed to the broader "initate a new (D)TLS connection" that could encompass both resumption and a full handshake? Section 3.2.2 If a Call Home DOTS client wants to redirect a Call Home DOTS server to another Call Home DOTS client, it MUST send a Non-confirmable PUT request to the predefined resource ".well-known/dots/redirect" with the new Call Home DOTS client FQDN or IP address in the body of the PUT similar to what is described in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. [...] I suggest that we mention the actual element in the YANG module that contains the structure that will be used as the PUT body, as this text in isolation feels like it's attempting to define the protocol by way of example and analogy, which is not a great pattern for protocol design. Section 3.3.1 In addition, the DOTS client MUST validate that attacker prefixes are within the scope of the DOTS server domain. What does "within the scope" mean in the context of the base signal channel? (i.e., the Call Home scenario depicted in Figure 7). The 'target- uri' or 'target-fqdn' parameters can be included in a mitigation request for diagnostic purposes to notify the Call Home DOTS server domain administrator, but SHOULD NOT be used to determine the target IP addresses. Note that 'target-prefix' becomes a mandatory attribute in the mitigation request signaling the attack information because 'target-uri' and 'target-fqdn' are optional attributes and 'alias-name' will not be conveyed in a mitigation request. I think we have to use normative language that 'target-prefix' is mandatory for call home, since the "don't rely on target-fqdn or target-uri' is not a MUST. (Actually, I think they would have to be "MUST NOT send", not just "MUST NOT rely on for identification", in order for us to be able to get away with the current wording that states it like a fact.) Also, we might want to explain why 'alias-name' cannot be used (and we don't need normative language to ensure it): they are created using the data channel but there is no call home data channel (yet, at least). In order to help attack source identification by a Call Home DOTS server, the Call Home DOTS client SHOULD include in its mitigation request additional information such as 'source-port-range' or 'source-icmp-type-range'. The Call Home DOTS client may not include such information if 'source-prefix' conveys an IPv6 address/prefix. I'm not sure what the "may not" is intending to convey, here. Are these mandaroy for IPv4 prefixes? The Call Home DOTS server MUST check that the 'source-prefix' is within the scope of the Call Home DOTS server domain. Note that in a (nit) this "MUST" seems redundant with the text I quoted previously. The Call Home DOTS server MUST check that the 'source-prefix' is within the scope of the Call Home DOTS server domain. Note that in a DOTS Call Home scenario, the Call Home DOTS server considers, by default, that any routeable IP prefix enclosed in 'target-prefix' is within the scope of the Call Home DOTS client. [...] We say "by default" -- how would some other behavior be activated? with or without DOTS server domain administrator consent. If the attack traffic is blocked, the Call Home DOTS server informs the Call Home DOTS client that the attack is being mitigated. This is just a normal 2.xx response code (and body) to the mitigation request? It might be worth clarifying. If the attack traffic information is identified by the Call Home DOTS server or the Call Home DOTS server domain administrator as legitimate traffic, the mitigation request is rejected, and 4.09 (Conflict) is returned to the Call Home DOTS client. The conflict- There may be quite some delay involved if the administrator needs to decide. Should we say more about (e.g.) using 5.03 and Max-Age in this case? Once the request is validated by the Call Home DOTS server, appropriate actions are enforced to block the attack traffic within the source network. The Call Home DOTS client is informed about the progress of the attack mitigation following the rules in [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS server is embedded in a CPE, it can program the packet processor to punt all the traffic from the compromised device to the target to I think the sentence about "informed about the progress" might be misplaced at this location within the paragraph -- the example given seems to just be talking about the "appropriate actions" that are taken for blocking traffic, not any mitigation-status updates. Section 3.3.2 If a Carrier Grade NAT (CGN, including NAT64) is located between the DOTS client domain and DOTS server domain, communicating an external IP address in a mitigation request is likely to be discarded by the Call Home DOTS server because the external IP address is not visible locally to the Call Home DOTS server (see Figure 10). The Call Home DOTS server is only aware of the internal IP addresses/prefixes bound to its domain. Thus, the Call Home DOTS client MUST NOT include the external IP address and/or port number identifying the suspect attack source, but MUST include the internal IP address and/or port number. We're likely to get similar complaints about "how will they know there's a NAT" that we did for the base signal channel. I don't have any great suggestions for trying to forestall such comments, though I do note that 8782 has some explicit text about "[t]his document does not make any recommendations about possible translator discovery mechanisms". Also, it's amusing that for the base signal channel we said to *not* use internal addresses, but for call home we say you have to use internal addresses. In the base signal channel we also said that we did not give recommendations on how to discover possible translator mechanisms... To that aim, the Call Home DOTS client SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the internal IP address ... yet here we seem to be making such recommendations! If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the provider's domain to service its customers, the identification of an attack source bound to an IPv4 address/prefix MUST also rely on source port numbers because the same IPv4 address is assigned to multiple customers. The port information is required to unambiguously identify the source of an attack. [same question about how to know that they are in use] If a translator is enabled on the boundaries of the domain hosting the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in Figures 11 and 12), the Call Home DOTS server uses the attack traffic information conveyed in a mitigation request to find the internal source IP address of the compromised device and blocks the traffic In a similar vein, I expect to get some questions about how the call home DOTS server finds the internal source IP address from the attack traffic information conveyed. I don't have a specific change to propose at this time, since I don't know, myself, but we should at least have some answer to give in response to such questions. The text is also a little unclear on why we provide both Figures 11 and 12 -- while both cases are valid, we don't seem to have any discussion that highlights differences between the cases. So perhaps we should say that the behavior of the call home DOTS server is the same whether or not the call home DOTS server is integrated with the CPE/NAT (if true)? Section 3.3.3 I think the YANG module might benefit from being moved up a level or two in the section hierarchy. Section 3.3.3.1 Should we give some indication that 'signal' is the import prefix for "ietf-dots-signal-channel" before going into the tree diagram? (I do not know what the convention is in this regard.) Section 3.3.3.2 I suggest reiterating the note from 8782 about needing to check the mapping output provided by YANG-to-CBOR in light of the situations where differing CBOR/JSON types can arise (e.g., enumerations and 64-bit quantities). I guess it's implicit that we reuse the CBOR map keys 8 and 9 for lower-port and upper-port in the source-port-range array? Section 3.3.3.3 This module uses the common YANG types defined in [RFC6991] and the data structure defined in [RFC8791]. (nit) I think we need another word here, maybe "data structure extension" or "data structure statement"? list source-icmp-type-range { key "lower-type"; description "ICMP type range. When only lower-type is present, it represents a single ICMP type."; It seems that the interpretation of the source-icmp-type-range list is dependent on the IP address family in use. Presumably one is supposed to infer this from the source-prefix (though we don't say so), but the source-prefix is optional when these fields are used in the base signal channel. It is not entirely clear whether it is safe to rely on the target-prefix for address-family determination, though (I do not recall any reason why DOTS signal channel doesn't work in the presence of a NAPT function). Should the icmp attributes only be allowed if the source-prefix is present? sx:augment-structure "/signal:dots-signal/signal:message-type/" + "signal:redirected-signal" { description "The alternate Call Home DOTS client."; Is there something we can/should do for the redirected-signal augmentation to indicate that the alt-server and alt-server-record nodes are removed/useless? leaf alt-ch-client { type string; description "FQDN of an alternate Call Home DOTS client."; Can we discuss a bit what the implications of redirection are for (D)TLS mutual authentication of the post-redirection channel? It seems that in most cases the alt-ch-client FQDN will be needed to perform certificate validation. Perhaps, though, there would be a case where a call home server has a set of preconfigured call home clients (each with IP address(es) and credentials), so a redirection by IP address to a different client in that set would still be functional. So, I am not sure that we need to make alt-ch-client a mandatory field (whether in the YANG or in the prose), but we probably do need to have some text earlier in the document covering the implications for authenticating the redirected-to peer. I note that in the base signal channel, alt-server is mandatory, so we would have some precendent for just making als-ch-client mandatory as well. Section 4.2 Table 2 doesn't seem consistent with Table 1 -- Table 1 lists a couple parameters that admit multiple CBOR types, but Table 2 only lists a single CBOR Major Type for them. Section 4.3 We don't have any visible note about removing TBA9 (and should probably add some text about 4 only being the *requested* value as well, though I'm pretty sure we'd know if there were other Standards Actions in the works that would be potentially requesting a conflicting value!). Section 5 We should probably say something about how the the call home channel is a potential vector for attack, with mitigation requests potentially causing the indicated device to be partially blocked or booted off the network entirely; mutual authentication of a trusted call home server, "a healthy dose of skepticism about the indicated attack" (or rather, local inspection of the indicated traffic), and involvement of the local administrator can mitigate the new risks that are opened up. This is related to what we currently have in the last paragraph, but we don't specifically discuss it as a new risk/attack vector due to this protocol. We might also consider referencing the security considerations of RFC 8071 (NETCONF/RESTCONF call home) since the "considerations not associated with server authentication" are likely similar. There may also be some considerations when the indicated attack source-prefix is in a private or local-use address range -- the "in scope" check at the call home server doesn't mean much. Common precautions mitigating DoS attacks are recommended, such as temporarily blacklisting the source address after a set number of unsuccessful authentication attempts. [I note that we used the term "drop-list" in RFC 8783.] Section 6 We should probably say something about how the use of DPI and similar IPS technologies will have privacy considerations of their own, but the specific considerations are specific to the specific device or technology in question (thus, out of scope for this specific document). Concretely, the protocol does not leak any new information that can be used to ease surveillance. In particular, the Call Home DOTS server is not required to share information that is local to its network (e.g., internal identifiers of an attack source) with the Call Home DOTS client. I guess it's true that we don't require the call-home server to share internal addresses with the call-home client, but we do require the call-home client to (only) use internal addresses in the mitigation request. Presumably the client has to learn those addresses somehow, and one could argue that this protocol is requiring that to happen even if it doesn't convey them in-band in that direction. So I think we need to say more about the privacy considerations of using internal addresses -- it's not safe to claim that it's out of scope. Also, this paragraph seems to be the main part that is directly privacy-relevant in this section -- would the other paragraphs be a better fit in the Security Considerations section? I guess the last paragraph does touch on privacy with the "not meant to track the activity of users", so it could stay here. Triggers to send a DOTS mitigation request to a Call Home DOTS server are deployment-specific. For example, a Call Home DOTS client may rely on the output of some DDoS detection systems deployed within the DOTS client domain to detect potential outbound DDoS attacks or on abuse claims received from remote victim networks. Such DDoS detection and mitigation techniques are not meant to track the activity of users, but to protect the Internet and avoid altering the IP reputation of the DOTS client domain. Perhaps we could say a little more about what steps this mechanism takes to avoid identifying users? E.g., the indicated data refer only to the source and target addresses where suspected attack flows are present; while it does permit expressing flow-level granularity there is no in-band protocol element that would correlate one suspected-attack flow with another suspected-attack flow as being associated with the same user. It is, however, possible that a faulty attack classification algorithm could consistently identify the legitimate behaviors of a particular user as being suspected attacks, in which case that user's traffic would consistently be flagged, but that user's traffic is still grouped in with the entire anonymity set of "all suspected attack traffic". Section 9.2 If the toolchain supports it, we should probably refer to RFC 4632 as BCP 122 in the text when we reference it. We may get someone asking for RFC 8612 to be normative since we expect the reader to be familiar with its terminology. It is only an informational document and is not on the downref registry, so in some sense it is "safer" to preemptively move it to being a normative reference that will automatically get called out as a downref during the IETF LC announcement; on the other hand, the IESG does have leeway to just approve it without another IETF LC if it does need to change from informative to normative as a result of IETF LC or IESG comments. I might suggest using a different slug for the [Sec] reference; the current short form is potentially misleading. Appendix A The other approach is signaling the role of each DOTS agent (e.g., by using the DOTS data channel). For example, the DOTS agent in the home network first initiates a DOTS data channel to the peer DOTS agent in the ISP environment, at this time the DOTS agent in the home network is the DOTS client and the peer DOTS agent in the ISP environment is the DOTS server. After that, the DOTS agent in the home network retrieves the DOTS Call Home capability of the peer DOTS agent. If the peer supports the DOTS Call Home, the DOTS agent needs to subscribe to the peer to use this extension. [...] I don't remember how such a capability negotiation on the data channel would work. Is it supposed to just be keying off of the peer's supported YANG modules or something like that? Might be worth clarifying. From nobody Tue Oct 13 21:31: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 95B573A1366; Tue, 13 Oct 2020 21:31: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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9D8H2Wrmp3cA; Tue, 13 Oct 2020 21:31:49 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3B69A3A1365; Tue, 13 Oct 2020 21:31:48 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09E4VgKe029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 00:31:47 -0400 Date: Tue, 13 Oct 2020 21:31:42 -0700 From: Benjamin Kaduk To: draft-ietf-dots-signal-call-home.all@ietf.org Cc: dots@ietf.org Message-ID: <20201014043142.GG50845@kduck.mit.edu> References: <20201013230819.GA50845@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201013230819.GA50845@kduck.mit.edu> Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 04:31:52 -0000 Oops, forgot to note that I also put a bunch of (hopefully!) editorial suggestions up at https://github.com/boucadair/dots-call-home/pull/1 rather than littering them here. -Ben On Tue, Oct 13, 2020 at 04:08:19PM -0700, Benjamin Kaduk wrote: > Hi all, > > Nothing super-earth-shattering in here, but there's enough that we'll need > a revised I-D and some more WG input before I'm ready to start the IETF LC. > > -Ben > > > YANG lint says: > > ietf-dots-call-home@2020-07-07.yang:11: warning: imported module > "ietf-dots-signal-channel" not used > > AFAICT that's a yanglint bug, since we do augment nodes from the signal > channel. > > I see that this document has a few IPR notices against it; in > particular, the one at https://datatracker.ietf.org/ipr/3318/ does not > list any licensing terms ("Unwilling to Commit to the Provisions of a), > b), or c) Above", where a/b/c are "no license needed for > implementation"/"RAND with no fee"/"RAND with possible fee"). > I believe we are working to see if the situation can be clarified and > the IPR disclosure updated, but I don't know that we need to delay any > progress until that has occurred. That said, personally, I'm not very > comfortable about a protocol that potentially is encumbered by IPR with > unknown license terms. However, I am willing to at least advance the > document to IETF LC if there is clear WG support for doing so, even > knowing that use of the protocol would potentially be subject to > arbitrary terms from the IPR holder. I would really like to hear from > the WG members on this point. > > I mention it in the section-by-section comments, but we introduce the > possibility of "wait for administrator approval" in the > mitigation-request processing pipeline, which could exceed a normal CoAP > request timeout. I think we need to have some substantive text > discussion the expected behavior in this case. > > Section 1.1 > > Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, > and Transport Layer Security (TLS) re-negotiation are difficult to > detect on a home network device without adversely affecting its > > (side note) TLS renegotiation as an attack is just keeping a TLS > connection open and repeatedly re-negotiating to cause the server to > burn CPU on signing operations? I don't think I've heard of that one > before. > > Section 1.2 > > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers > to a DOTS signal channel established at the initiative of a DOTS > server. That is, the DOTS server initiates a secure connection to a > DOTS client, and uses that connection to receive the attack traffic > information (e.g., attack sources) from the DOTS client. More > details are provided in Section 3. > > I think this introductory section needs to be crystal clear for the > reader about the relationship between the "conventional" signal channel > DOTS client and the corresponding call home DOTS client for a given > mitigation process. Some people will expect both things with "client" > in the name to be on the same device, and some people will expect the > (call home) client to be the device that makes mitigation requests, but > both cannot be right. The phrase "role reversal" might be useful in > describing these interpretations, as might a forward reference to > section 1.4. (Yes, I understand that there is no need for either DOTS > call home peer to be colocated with any base signal channel element, but > I think that the default scenario in many readers' minds will be the > simple role-reversal setup.) > > Section 1.3 > > It's a little unfortunate that we are using the "DMS" acronym in the > figure here, when we only mention the terminology of RFC 8612 in section > 2. (That said, I'm willing to leave it as-is for now and see if anyone > complains.) > > Section 3.1 > > The DOTS signal channel Call Home preserves all but one of the DOTS > client/server roles in the DOTS protocol stack, as compared to DOTS > client-initiated DOTS signal channel protocol > > I suppose one could quibble about whether "party allowed to behave > passively with respect to heartbeats" qualifies as a "client/server > role" ... I think I'm okay leaving this as-is for now, though. > > For example, a home network element (e.g., home router) co-located > with a Call Home DOTS server is the (D)TLS server. However, when > > Figure 7 has a box labelled "Call Home DOTS server" and also "(D)TLS > client" (not server). At first I thought this was trying to make an > analogy to a (normal) signal channel DOTS server as being the (D)TLS > server, but that would not be in a home network element. So maybe this > is just a typo? > > calling home, the DOTS server initially assumes the role of the > (D)TLS client, but the network element's role as a DOTS server > > We may want to continue using "DOTS Call Home server" in these two lines. > > remains the same. Furthermore, existing certificate chains and > mutual authentication mechanisms between the DOTS agents are > unaffected by the Call Home function. This Call Home function > > This may merit a bit more text, or at least a bit more thought, since we > are now asking the certificate validation to be used for a different > logical purpose. While it's true that the entity acting as a (D)TLS > server is likely to be the same device as a regular DOTS server (or at > least operated by the same DMS provider), and so there is a fairly > strong analogue there in terms of the (D)TLS server certificate > validation procedures, the (D)TLS client is something of a different > entity than a traditional DOTS client. It's true that RFC 8782 leaves > the specifics of the mutual authentication a bit under-specified (and > essentially just says that it has to happen somehow), but one might > imagine that the number of DOTS clients are fairly small and tied to > specific legal contracts, so manual provisioning (or provisioning during > onboarding) of client certificate information is reasonable. For the > call home case, we should expect a lot more call home DOTS servers > (i.e., (D)TLS clients) and thus should probably have a better story for > automating the mutual authentication check. Defining an > extendedKeyUsage value that indicate authorization to act as a call home > server would be one typical way to do so (it's perhaps unfortunate that > we didn't define an EKU for DOTS client usage), but if we're not going > to do that we should at least put some words in about how the mutual > authentication requirement remains but a different ACL may be needed for > call home than for traditional DOTS sessions. > > enables the DOTS server co-located with a network element (possibly > > (Still Call Home server, right?) > > Section 3.2.1 > > If the Call Home DOTS server does not receive any traffic from the > peer Call Home DOTS client during the time span required to exhaust > the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server > concludes the session is disconnected. Then, the Call Home DOTS > server MUST try to resume the (D)TLS session. > > Why resume specifically, as opposed to the broader "initate a new (D)TLS > connection" that could encompass both resumption and a full handshake? > > Section 3.2.2 > > If a Call Home DOTS client wants to redirect a Call Home DOTS server > to another Call Home DOTS client, it MUST send a Non-confirmable PUT > request to the predefined resource ".well-known/dots/redirect" with > the new Call Home DOTS client FQDN or IP address in the body of the > PUT similar to what is described in Section 4.6 of > [I-D.ietf-dots-rfc8782-bis]. [...] > > I suggest that we mention the actual element in the YANG module that > contains the structure that will be used as the PUT body, as this text > in isolation feels like it's attempting to define the protocol by way of > example and analogy, which is not a great pattern for protocol design. > > Section 3.3.1 > > In > addition, the DOTS client MUST validate that attacker prefixes are > within the scope of the DOTS server domain. > > What does "within the scope" mean in the context of the base signal > channel? > > (i.e., the Call Home scenario depicted in Figure 7). The 'target- > uri' or 'target-fqdn' parameters can be included in a mitigation > request for diagnostic purposes to notify the Call Home DOTS server > domain administrator, but SHOULD NOT be used to determine the target > IP addresses. Note that 'target-prefix' becomes a mandatory > attribute in the mitigation request signaling the attack information > because 'target-uri' and 'target-fqdn' are optional attributes and > 'alias-name' will not be conveyed in a mitigation request. > > I think we have to use normative language that 'target-prefix' is > mandatory for call home, since the "don't rely on target-fqdn or > target-uri' is not a MUST. (Actually, I think they would have to be > "MUST NOT send", not just "MUST NOT rely on for identification", in > order for us to be able to get away with the current wording that states > it like a fact.) > > Also, we might want to explain why 'alias-name' cannot be used (and we > don't need normative language to ensure it): they are created using the > data channel but there is no call home data channel (yet, at least). > > In order to help attack source identification by a Call Home DOTS > server, the Call Home DOTS client SHOULD include in its mitigation > request additional information such as 'source-port-range' or > 'source-icmp-type-range'. The Call Home DOTS client may not include > such information if 'source-prefix' conveys an IPv6 address/prefix. > > I'm not sure what the "may not" is intending to convey, here. Are these > mandaroy for IPv4 prefixes? > > The Call Home DOTS server MUST check that the 'source-prefix' is > within the scope of the Call Home DOTS server domain. Note that in a > > (nit) this "MUST" seems redundant with the text I quoted previously. > > The Call Home DOTS server MUST check that the 'source-prefix' is > within the scope of the Call Home DOTS server domain. Note that in a > DOTS Call Home scenario, the Call Home DOTS server considers, by > default, that any routeable IP prefix enclosed in 'target-prefix' is > within the scope of the Call Home DOTS client. [...] > > We say "by default" -- how would some other behavior be activated? > > with or without DOTS server domain administrator consent. If the > attack traffic is blocked, the Call Home DOTS server informs the Call > Home DOTS client that the attack is being mitigated. > > This is just a normal 2.xx response code (and body) to the mitigation > request? It might be worth clarifying. > > If the attack traffic information is identified by the Call Home DOTS > server or the Call Home DOTS server domain administrator as > legitimate traffic, the mitigation request is rejected, and 4.09 > (Conflict) is returned to the Call Home DOTS client. The conflict- > > There may be quite some delay involved if the administrator needs to > decide. Should we say more about (e.g.) using 5.03 and Max-Age in this > case? > > Once the request is validated by the Call Home DOTS server, > appropriate actions are enforced to block the attack traffic within > the source network. The Call Home DOTS client is informed about the > progress of the attack mitigation following the rules in > [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS > server is embedded in a CPE, it can program the packet processor to > punt all the traffic from the compromised device to the target to > > I think the sentence about "informed about the progress" might be > misplaced at this location within the paragraph -- the example given seems to > just be talking about the "appropriate actions" that are taken for blocking > traffic, not any mitigation-status updates. > > Section 3.3.2 > > If a Carrier Grade NAT (CGN, including NAT64) is located between the > DOTS client domain and DOTS server domain, communicating an external > IP address in a mitigation request is likely to be discarded by the > Call Home DOTS server because the external IP address is not visible > locally to the Call Home DOTS server (see Figure 10). The Call Home > DOTS server is only aware of the internal IP addresses/prefixes bound > to its domain. Thus, the Call Home DOTS client MUST NOT include the > external IP address and/or port number identifying the suspect attack > source, but MUST include the internal IP address and/or port number. > > We're likely to get similar complaints about "how will they know there's > a NAT" that we did for the base signal channel. I don't have any great > suggestions for trying to forestall such comments, though I do note that > 8782 has some explicit text about "[t]his document does not make any > recommendations about possible translator discovery mechanisms". > > Also, it's amusing that for the base signal channel we said to *not* > use internal addresses, but for call home we say you have to use > internal addresses. In the base signal channel we also said that we did > not give recommendations on how to discover possible translator > mechanisms... > > To that aim, the Call Home DOTS client SHOULD rely on mechanisms, > such as [RFC8512] or [RFC8513], to retrieve the internal IP address > > ... yet here we seem to be making such recommendations! > > If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the > provider's domain to service its customers, the identification of an > attack source bound to an IPv4 address/prefix MUST also rely on > source port numbers because the same IPv4 address is assigned to > multiple customers. The port information is required to > unambiguously identify the source of an attack. > > [same question about how to know that they are in use] > > If a translator is enabled on the boundaries of the domain hosting > the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in > Figures 11 and 12), the Call Home DOTS server uses the attack traffic > information conveyed in a mitigation request to find the internal > source IP address of the compromised device and blocks the traffic > > In a similar vein, I expect to get some questions about how the call > home DOTS server finds the internal source IP address from the attack > traffic information conveyed. I don't have a specific change to propose > at this time, since I don't know, myself, but we should at least have > some answer to give in response to such questions. > > The text is also a little unclear on why we provide both Figures 11 and > 12 -- while both cases are valid, we don't seem to have any discussion > that highlights differences between the cases. So perhaps we should say > that the behavior of the call home DOTS server is the same whether or > not the call home DOTS server is integrated with the CPE/NAT (if true)? > > Section 3.3.3 > > I think the YANG module might benefit from being moved up a level or two > in the section hierarchy. > > Section 3.3.3.1 > > Should we give some indication that 'signal' is the import prefix for > "ietf-dots-signal-channel" before going into the tree diagram? (I do > not know what the convention is in this regard.) > > Section 3.3.3.2 > > I suggest reiterating the note from 8782 about needing to check the > mapping output provided by YANG-to-CBOR in light of the situations where > differing CBOR/JSON types can arise (e.g., enumerations and 64-bit > quantities). > > I guess it's implicit that we reuse the CBOR map keys 8 and 9 for > lower-port and upper-port in the source-port-range array? > > Section 3.3.3.3 > > This module uses the common YANG types defined in [RFC6991] and the > data structure defined in [RFC8791]. > > (nit) I think we need another word here, maybe "data structure > extension" or "data structure statement"? > > list source-icmp-type-range { > key "lower-type"; > description > "ICMP type range. When only lower-type is > present, it represents a single ICMP type."; > > It seems that the interpretation of the source-icmp-type-range list is > dependent on the IP address family in use. Presumably one is supposed > to infer this from the source-prefix (though we don't say so), but the > source-prefix is optional when these fields are used in the base signal > channel. It is not entirely clear whether it is safe to rely on the > target-prefix for address-family determination, though (I do not recall > any reason why DOTS signal channel doesn't work in the presence of a > NAPT function). Should the icmp attributes only be allowed if the > source-prefix is present? > > sx:augment-structure "/signal:dots-signal/signal:message-type/" > + "signal:redirected-signal" { > description > "The alternate Call Home DOTS client."; > > Is there something we can/should do for the redirected-signal > augmentation to indicate that the alt-server and alt-server-record nodes > are removed/useless? > > leaf alt-ch-client { > type string; > description > "FQDN of an alternate Call Home DOTS client."; > > Can we discuss a bit what the implications of redirection are for (D)TLS > mutual authentication of the post-redirection channel? It seems that in > most cases the alt-ch-client FQDN will be needed to perform certificate > validation. Perhaps, though, there would be a case where a call home > server has a set of preconfigured call home clients (each with IP > address(es) and credentials), so a redirection by IP address to a > different client in that set would still be functional. So, I am not > sure that we need to make alt-ch-client a mandatory field (whether in > the YANG or in the prose), but we probably do need to have some text > earlier in the document covering the implications for authenticating the > redirected-to peer. I note that in the base signal channel, alt-server > is mandatory, so we would have some precendent for just making > als-ch-client mandatory as well. > > Section 4.2 > > Table 2 doesn't seem consistent with Table 1 -- Table 1 lists a couple > parameters that admit multiple CBOR types, but Table 2 only lists a > single CBOR Major Type for them. > > Section 4.3 > > We don't have any visible note about removing TBA9 (and should probably > add some text about 4 only being the *requested* value as well, though > I'm pretty sure we'd know if there were other Standards Actions in the > works that would be potentially requesting a conflicting value!). > > Section 5 > > We should probably say something about how the the call home channel is > a potential vector for attack, with mitigation requests potentially > causing the indicated device to be partially blocked or booted off the > network entirely; mutual authentication of a trusted call home server, > "a healthy dose of skepticism about the indicated attack" (or > rather, local inspection of the indicated traffic), and involvement of > the local administrator can mitigate the new risks that are opened up. > This is related to what we currently have in the last paragraph, but we > don't specifically discuss it as a new risk/attack vector due to this > protocol. > > We might also consider referencing the security considerations of RFC > 8071 (NETCONF/RESTCONF call home) since the "considerations not > associated with server authentication" are likely similar. > > There may also be some considerations when the indicated attack > source-prefix is in a private or local-use address range -- the "in > scope" check at the call home server doesn't mean much. > > Common precautions mitigating DoS attacks are recommended, such as > temporarily blacklisting the source address after a set number of > unsuccessful authentication attempts. > > [I note that we used the term "drop-list" in RFC 8783.] > > Section 6 > > We should probably say something about how the use of DPI and similar > IPS technologies will have privacy considerations of their own, but the > specific considerations are specific to the specific device or > technology in question (thus, out of scope for this specific document). > > Concretely, the protocol does not leak any new information that can > be used to ease surveillance. In particular, the Call Home DOTS > server is not required to share information that is local to its > network (e.g., internal identifiers of an attack source) with the > Call Home DOTS client. > > I guess it's true that we don't require the call-home server to share > internal addresses with the call-home client, but we do require the > call-home client to (only) use internal addresses in the mitigation > request. Presumably the client has to learn those addresses somehow, > and one could argue that this protocol is requiring that to happen even > if it doesn't convey them in-band in that direction. So I think we need > to say more about the privacy considerations of using internal addresses > -- it's not safe to claim that it's out of scope. > > Also, this paragraph seems to be the main part that is directly > privacy-relevant in this section -- would the other paragraphs be a > better fit in the Security Considerations section? I guess the last > paragraph does touch on privacy with the "not meant to track the > activity of users", so it could stay here. > > Triggers to send a DOTS mitigation request to a Call Home DOTS server > are deployment-specific. For example, a Call Home DOTS client may > rely on the output of some DDoS detection systems deployed within the > DOTS client domain to detect potential outbound DDoS attacks or on > abuse claims received from remote victim networks. Such DDoS > detection and mitigation techniques are not meant to track the > activity of users, but to protect the Internet and avoid altering the > IP reputation of the DOTS client domain. > > Perhaps we could say a little more about what steps this mechanism takes > to avoid identifying users? E.g., the indicated data refer only to the > source and target addresses where suspected attack flows are present; > while it does permit expressing flow-level granularity there is no > in-band protocol element that would correlate one suspected-attack flow > with another suspected-attack flow as being associated with the same > user. It is, however, possible that a faulty attack classification > algorithm could consistently identify the legitimate behaviors of a > particular user as being suspected attacks, in which case that user's > traffic would consistently be flagged, but that user's traffic is still > grouped in with the entire anonymity set of "all suspected attack > traffic". > > Section 9.2 > > If the toolchain supports it, we should probably refer to RFC 4632 as > BCP 122 in the text when we reference it. > > We may get someone asking for RFC 8612 to be normative since we expect > the reader to be familiar with its terminology. It is only an > informational document and is not on the downref registry, so in some > sense it is "safer" to preemptively move it to being a normative > reference that will automatically get called out as a downref during the > IETF LC announcement; on the other hand, the IESG does have leeway to > just approve it without another IETF LC if it does need to change from > informative to normative as a result of IETF LC or IESG comments. > > I might suggest using a different slug for the [Sec] reference; the > current short form is potentially misleading. > > Appendix A > > The other approach is signaling the role of each DOTS agent (e.g., by > using the DOTS data channel). For example, the DOTS agent in the > home network first initiates a DOTS data channel to the peer DOTS > agent in the ISP environment, at this time the DOTS agent in the home > network is the DOTS client and the peer DOTS agent in the ISP > environment is the DOTS server. After that, the DOTS agent in the > home network retrieves the DOTS Call Home capability of the peer DOTS > agent. If the peer supports the DOTS Call Home, the DOTS agent needs > to subscribe to the peer to use this extension. [...] > > I don't remember how such a capability negotiation on the data channel > would work. Is it supposed to just be keying off of the peer's > supported YANG modules or something like that? Might be worth > clarifying. > From nobody Wed Oct 14 04:44: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 960FC3A08BA; Wed, 14 Oct 2020 04:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBPeMYuQ9wgw; Wed, 14 Oct 2020 04:44:08 -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 A80373A08B9; Wed, 14 Oct 2020 04:44:07 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4CB9YL0WxJz2yly; Wed, 14 Oct 2020 13:44:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602675846; bh=enZ+MK7tbPZkfBs5mp//klLQUKvuWx59m3bhiUvvUjs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rqlXSVWqq8x7XMBj6rOjCFWzBfQhpur3uSS9pvy4j3o6xq7vqILGchIeRvot5TABB GuXGd4x1sy38n/8Desn6m46gG/45WFKt0enTZ3QPnPSCHq9UsNLCvjqB061ZqsVvpz +GrtIRNonp/nZBBIznkN/BsB5DSn4ek5PG9JXxJq9A8AjrT0/tFvutuO6OaRNEDswk Z84VV4ivWBemxXhVgEe2EJpXnqh0vb9r3ieFUqTyzHoSsrcLd13u9ulVB4hbHkgk/a Ro7p3/2h4MUJTQorm4p0DGqrJdhTVvr6iPWP/KGVzDagPf3ulGjHvjWXn31lfhpF47 L/iX3qLZIwMAA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4CB9YK6bnQz2xFN; Wed, 14 Oct 2020 13:44:05 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-call-home.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: AD evaluation of draft-ietf-dots-signal-call-home-09: Section 1 Thread-Index: AdaiH095FkE6ynwuQZivFJelvxru2A== Date: Wed, 14 Oct 2020 11:44:05 +0000 Message-ID: <7048_1602675845_5F86E485_7048_112_3_787AE7BB302AE849A7480A190F8B93303155FF8F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 1 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 11:44:10 -0000 Hi Ben,=20 Thank you for the detailed review. Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mercredi 14 octobre 2020 01:08 > =C0=A0: draft-ietf-dots-signal-call-home.all@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: AD evaluation of draft-ietf-dots-signal-call-home-09 >=20 > Hi all, >=20 > Nothing super-earth-shattering in here, but there's enough that > we'll need a revised I-D and some more WG input before I'm ready to > start the IETF LC. >=20 > -Ben >=20 >=20 > YANG lint says: >=20 > ietf-dots-call-home@2020-07-07.yang:11: warning: imported module > "ietf-dots-signal-channel" not used >=20 > AFAICT that's a yanglint bug, since we do augment nodes from the > signal channel. [Med] Yes, it is a pyang issue. We have a similar warning for RFC8791 (wher= e sx is defined): =3D=3D $ pyang -f tree --tree-print-structures example-module-aug\@2020-07-07.yang example-module-aug@2020-07-07.yang:9: warning: imported module "example-mod= ule" not used module: example-module-aug augment-structure /exm:address-book/exm:address: +-- county? string +-- zipcode? string =3D=3D >=20 > I see that this document has a few IPR notices against it; in > particular, the one at https://datatracker.ietf.org/ipr/3318/ does > not list any licensing terms ("Unwilling to Commit to the Provisions > of a), b), or c) Above", where a/b/c are "no license needed for > implementation"/"RAND with no fee"/"RAND with possible fee"). > I believe we are working to see if the situation can be clarified > and the IPR disclosure updated, but I don't know that we need to > delay any progress until that has occurred. That said, personally, > I'm not very comfortable about a protocol that potentially is > encumbered by IPR with unknown license terms. However, I am willing > to at least advance the document to IETF LC if there is clear WG > support for doing so, even knowing that use of the protocol would > potentially be subject to arbitrary terms from the IPR holder. I > would really like to hear from the WG members on this point. [Med] Actually, there is only one IPR disclosure (3328) that is directly ma= de for the document. Some more information below:=20 * The two IPR disclosures (3318/3337) were made in early stages of the deve= lopment of the individual submission, especially before WG adoption. * 3328 is not a new disclosure but an update of 3337 to point to the wg-ado= pted version. A note was sent to the chairs to inform them about the update= .=20=20 * I'm not sure that IPR disclosures are transitive. 3318 is not filled dire= ctly against draft-ietf-dots-signal-call-home. >=20 > I mention it in the section-by-section comments, but we introduce > the possibility of "wait for administrator approval" in the > mitigation-request processing pipeline, which could exceed a normal > CoAP request timeout. I think we need to have some substantive text > discussion the expected behavior in this case. [Med] There is no request timeout because a request that requires an admin = validation can be first replied with attack-mitigation-in-progress status. = If the request is then rejected by the admin, the status will change to att= ack-mitigation-withdrawn with conflict-status set to the new code "mitigati= on-request-rejected" defined in the document.=20 Will add more text. >=20 > Section 1.1 >=20 > Some of the DDoS attacks like spoofed RST or FIN packets, > Slowloris, > and Transport Layer Security (TLS) re-negotiation are difficult > to > detect on a home network device without adversely affecting its >=20 > (side note) TLS renegotiation as an attack is just keeping a TLS > connection open and repeatedly re-negotiating to cause the server to > burn CPU on signing operations? [Med] Yes. I don't think I've heard of that > one before. [Med] Some DoS tools are supporting this, but I don't have data about recen= t attacks exploiting it. Unless there is an objection (Tiru?), I would remo= ve the example as we don't need to be exhaustive anyway.=20 >=20 > Section 1.2 >=20 > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) > refers > to a DOTS signal channel established at the initiative of a DOTS > server. That is, the DOTS server initiates a secure connection > to a > DOTS client, and uses that connection to receive the attack > traffic > information (e.g., attack sources) from the DOTS client. More > details are provided in Section 3. >=20 > I think this introductory section needs to be crystal clear for the > reader about the relationship between the "conventional" signal > channel DOTS client and the corresponding call home DOTS client for > a given mitigation process. Some people will expect both things > with "client" > in the name to be on the same device, and some people will expect > the (call home) client to be the device that makes mitigation > requests, but both cannot be right. The phrase "role reversal" > might be useful in describing these interpretations, as might a > forward reference to section 1.4. (Yes, I understand that there is > no need for either DOTS call home peer to be colocated with any base > signal channel element, but I think that the default scenario in > many readers' minds will be the simple role-reversal setup.) >=20 [Med] The NEW text is as follows:=20 NEW: 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers to a DOTS signal channel established at the initiative of a DOTS server thanks to a role reversal at the (D)TLS layer (Section 3.1). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That is, the DOTS server initiates a secure connection to a DOTS client, and uses that connection to receive the attack traffic information (e.g., attack sources) from the DOTS client. DOTS agents involved in the DOTS Call Home adhere to the DOTS roles as defined in [RFC8612]. For clarity, this document uses "Call Home DOTS client" (or "Call Home DOTS server") to refer to a DOTS client (or DOTS server) deployed in a Call Home scenario (Figure 1). DOTS Call Home agents may (or not) be co-located with DOTS agents that are ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ compliant with [I-D.ietf-dots-rfc8782-bis] (see Section 1.4 for more ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ details). > Section 1.3 >=20 > It's a little unfortunate that we are using the "DMS" acronym in the > figure here, when we only mention the terminology of RFC 8612 in > section 2. (That said, I'm willing to leave it as-is for now and > see if anyone > complains.) [Med] Added this NEW text to the terminology section: DDoS Mitigation System (DMS) refers to a system that performs DDoS mitigation. >=20 > Section 3.1 >=20 > The DOTS signal channel Call Home preserves all but one of the > DOTS > client/server roles in the DOTS protocol stack, as compared to > DOTS > client-initiated DOTS signal channel protocol >=20 > I suppose one could quibble about whether "party allowed to behave > passively with respect to heartbeats" qualifies as a "client/server > role" ... I think I'm okay leaving this as-is for now, though. >=20 > For example, a home network element (e.g., home router) co- > located > with a Call Home DOTS server is the (D)TLS server. However, when >=20 > Figure 7 has a box labelled "Call Home DOTS server" and also "(D)TLS > client" (not server). At first I thought this was trying to make an > analogy to a (normal) signal channel DOTS server as being the (D)TLS > server, but that would not be in a home network element. So maybe > this is just a typo? [Med] This is a typo in the text. The figure is correct. Thanks for catchin= g this.=20 >=20 > calling home, the DOTS server initially assumes the role of the > (D)TLS client, but the network element's role as a DOTS server >=20 > We may want to continue using "DOTS Call Home server" in these two > lines. [Med] OK. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 14 06:27: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 7D7CE3A0A9F; Wed, 14 Oct 2020 06:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn-R0ZrGEuv5; Wed, 14 Oct 2020 06:27:27 -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 DEA373A0A88; Wed, 14 Oct 2020 06:27:26 -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 4CBCrY1qKyz7vr7; Wed, 14 Oct 2020 15:27:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602682045; bh=Wt52L45yY9L/amIzyXhfHevjIL5ue2c26yl3OZENUIQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=atfMfiWn8r4hjTNjn6hlGC/grKjbsnUL8oVKmOJE+NaLguAV/g2/H5tDwa9VRcdIu 92+xQPCpSFN3HQyYZkDful5fUmk3Rti/Z43pNf7hNHsrc6fyFaJVSGexqi68vV0Euf U3sLjXlSNaWgX/E7lgBU9bMKiLKAUm2fRxGXp0nXM3EPKzxGB9wdzKqX/eSnXe2aLd 6L/JSt/MhfLqICLed8UdetP8V6lZgNLRyvMSXUtRCosluFPQThWFyFMxnHSkDNyoic CBdx6dsWP2/Ec2XHWWre163LfFhA9nrma8T2iWhuivCWMA0Gq5F2HZbubOCf1bSlq4 7pzyrP0JDaV+Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4CBCrY0mqvzCqlD; Wed, 14 Oct 2020 15:27:25 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-call-home.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3 Thread-Index: AdaiLb2gAg0ZMeEeQSKvjeSuGuDvhA== Date: Wed, 14 Oct 2020 13:27:24 +0000 Message-ID: <23440_1602682045_5F86FCBD_23440_36_1_787AE7BB302AE849A7480A190F8B933031560069@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 13:27:30 -0000 Re- Please see inline. Cheers, Med =20 > remains the same. Furthermore, existing certificate chains and > mutual authentication mechanisms between the DOTS agents are > unaffected by the Call Home function. This Call Home function >=20 > This may merit a bit more text, or at least a bit more thought, > since we are now asking the certificate validation to be used for a > different logical purpose. While it's true that the entity acting > as a (D)TLS server is likely to be the same device as a regular DOTS > server (or at least operated by the same DMS provider), and so there > is a fairly strong analogue there in terms of the (D)TLS server > certificate validation procedures, the (D)TLS client is something of > a different entity than a traditional DOTS client. It's true that > RFC 8782 leaves the specifics of the mutual authentication a bit > under-specified (and essentially just says that it has to happen > somehow), but one might imagine that the number of DOTS clients are > fairly small and tied to specific legal contracts, so manual > provisioning (or provisioning during > onboarding) of client certificate information is reasonable. For > the call home case, we should expect a lot more call home DOTS > servers (i.e., (D)TLS clients) and thus should probably have a > better story for automating the mutual authentication check. > Defining an extendedKeyUsage value that indicate authorization to > act as a call home server would be one typical way to do so (it's > perhaps unfortunate that we didn't define an EKU for DOTS client > usage), but if we're not going to do that we should at least put > some words in about how the mutual authentication requirement > remains but a different ACL may be needed for call home than for > traditional DOTS sessions. Med: I admit that I don't see a difference between the two. I let Tiru and = Jon share their views on this.=20 >=20 > enables the DOTS server co-located with a network element > (possibly >=20 > (Still Call Home server, right?) Med: Yes. Update the text for better clarity:=20 This Call Home function enables the Call Home DOTS server co-located with a network element (possibly behind NATs and firewalls) reachable by only the intended Call Home DOTS client and hence the Call Home DOTS server cannot be subjected to these DDoS attacks. >=20 > Section 3.2.1 >=20 > If the Call Home DOTS server does not receive any traffic from > the > peer Call Home DOTS client during the time span required to > exhaust > the maximum 'missing-hb-allowed' threshold, the Call Home DOTS > server > concludes the session is disconnected. Then, the Call Home DOTS > server MUST try to resume the (D)TLS session. >=20 > Why resume specifically, as opposed to the broader "initate a new > (D)TLS connection" that could encompass both resumption and a full > handshake? [Med] A new connection will be used if resumption fails. This is handled by= the DTLS layer.=20=20=20 Jon, can please confirm/infirm this how your implementation works? Thanks.= =20 >=20 > Section 3.2.2 >=20 > If a Call Home DOTS client wants to redirect a Call Home DOTS > server > to another Call Home DOTS client, it MUST send a Non-confirmable > PUT > request to the predefined resource ".well-known/dots/redirect" > with > the new Call Home DOTS client FQDN or IP address in the body of > the > PUT similar to what is described in Section 4.6 of > [I-D.ietf-dots-rfc8782-bis]. [...] >=20 > I suggest that we mention the actual element in the YANG module that > contains the structure that will be used as the PUT body, as this > text in isolation feels like it's attempting to define the protocol > by way of example and analogy, which is not a great pattern for > protocol design. [Med] Fair comment. Added this new text:=20 the following attributes in the body of the PUT request: alt-ch-client: The FQDN of an alternate Call Home DOTS client. This is a mandatory attribute for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations. alt-ch-client-record: List of records for the alternate Call Home DOTS client. This is an optional attribute for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations. ttl: The Time to live (TTL) of the alternate Call Home DOTS client. That is, the time interval that the alternate Call Home DOTS client may be cached for use by a Call Home DOTS server. This is an optional attribute for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations.=20 >=20 > Section 3.3.1 >=20 >=20 > In > addition, the DOTS client MUST validate that attacker prefixes > are > within the scope of the DOTS server domain. >=20 > What does "within the scope" mean in the context of the base signal > channel? [Med] The analogy with the base signal channel is to make sure that the IP = resources are associated with the DOTS client domain. For the call home cas= e, these resources must be bound to the call home dots server domain.=20 >=20 > (i.e., the Call Home scenario depicted in Figure 7). The > 'target- > uri' or 'target-fqdn' parameters can be included in a mitigation > request for diagnostic purposes to notify the Call Home DOTS > server > domain administrator, but SHOULD NOT be used to determine the > target > IP addresses. Note that 'target-prefix' becomes a mandatory > attribute in the mitigation request signaling the attack > information > because 'target-uri' and 'target-fqdn' are optional attributes > and > 'alias-name' will not be conveyed in a mitigation request. >=20 > I think we have to use normative language that 'target-prefix' is > mandatory for call home, since the "don't rely on target-fqdn or > target-uri' is not a MUST. (Actually, I think they would have to be > "MUST NOT send", not just "MUST NOT rely on for identification", in > order for us to be able to get away with the current wording that > states it like a fact.) [Med] I'm afraid this is redundant with RFC8782 that says:=20 In the PUT request, at least one of the attributes 'target-prefix', 'target-fqdn','target-uri', or 'alias-name' MUST be present.=20 >=20 > Also, we might want to explain why 'alias-name' cannot be used (and > we don't need normative language to ensure it): they are created > using the data channel but there is no call home data channel (yet, > at least). [Med] The target can be any address, not only those managed by a call home = DOTS client. Even if RESTCONF Call Home (RFC8071)+ DOTS Data Channel are en= abled, there is no viable use case for a call home DOTS client to create al= iases and for the server (a CPE, for example) to store them.=20 I propose to change to "and 'alias-name' is unlikely to be conveyed in a mi= tigation request.". Not sure if it is worth to add a note.=20 >=20 > In order to help attack source identification by a Call Home DOTS > server, the Call Home DOTS client SHOULD include in its > mitigation > request additional information such as 'source-port-range' or > 'source-icmp-type-range'. The Call Home DOTS client may not > include > such information if 'source-prefix' conveys an IPv6 > address/prefix. >=20 > I'm not sure what the "may not" is intending to convey, here. [Med] This to say that an IPv6 address would be sufficient to identify an i= nternal host.=20 Are > these mandaroy for IPv4 prefixes? [Med] Because of the NAT, a singled source address may be shared. Providing= these additional attributes is recommended to hep identifying the internal= IP address. >=20 > The Call Home DOTS server MUST check that the 'source-prefix' is > within the scope of the Call Home DOTS server domain. Note that > in a >=20 > (nit) this "MUST" seems redundant with the text I quoted previously. [Med] The first one was on the client side. This one at the server side.=20 >=20 > The Call Home DOTS server MUST check that the 'source-prefix' is > within the scope of the Call Home DOTS server domain. Note that > in a > DOTS Call Home scenario, the Call Home DOTS server considers, by > default, that any routeable IP prefix enclosed in 'target-prefix' > is > within the scope of the Call Home DOTS client. [...] >=20 > We say "by default" -- how would some other behavior be activated? [Med] local configuration.=20 >=20 > with or without DOTS server domain administrator consent. If the > attack traffic is blocked, the Call Home DOTS server informs the > Call > Home DOTS client that the attack is being mitigated. >=20 > This is just a normal 2.xx response code (and body) to the > mitigation request? It might be worth clarifying. Med: Fixed.=20 >=20 > If the attack traffic information is identified by the Call Home > DOTS > server or the Call Home DOTS server domain administrator as > legitimate traffic, the mitigation request is rejected, and 4.09 > (Conflict) is returned to the Call Home DOTS client. The > conflict- >=20 > There may be quite some delay involved if the administrator needs to > decide. Should we say more about (e.g.) using 5.03 and Max-Age in > this case? Med: Already answer in the first part. >=20 > Once the request is validated by the Call Home DOTS server, > appropriate actions are enforced to block the attack traffic > within > the source network. The Call Home DOTS client is informed about > the > progress of the attack mitigation following the rules in > [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS > server is embedded in a CPE, it can program the packet processor > to > punt all the traffic from the compromised device to the target to >=20 > I think the sentence about "informed about the progress" might be > misplaced at this location within the paragraph -- the example given > seems to just be talking about the "appropriate actions" that are > taken for blocking traffic, not any mitigation-status updates. Med: Rearranged the text accordingly.=20 >=20 > Section 3.3.2 >=20 > If a Carrier Grade NAT (CGN, including NAT64) is located between > the > DOTS client domain and DOTS server domain, communicating an > external > IP address in a mitigation request is likely to be discarded by > the > Call Home DOTS server because the external IP address is not > visible > locally to the Call Home DOTS server (see Figure 10). The Call > Home > DOTS server is only aware of the internal IP addresses/prefixes > bound > to its domain. Thus, the Call Home DOTS client MUST NOT include > the > external IP address and/or port number identifying the suspect > attack > source, but MUST include the internal IP address and/or port > number. >=20 > We're likely to get similar complaints about "how will they know > there's a NAT" that we did for the base signal channel. I don't > have any great suggestions for trying to forestall such comments, > though I do note that > 8782 has some explicit text about "[t]his document does not make any > recommendations about possible translator discovery mechanisms". Med: The target deployment model is a service provider that want to preserv= e the reputation of its network. The CGN and the Call Home DOTS client are = likely to be owned by that same SP. In such case, the information about the= presence of address sharing is given.=20=20 >=20 > Also, it's amusing that for the base signal channel we said to *not* > use internal addresses, Med: which is normal because the internal addresses are private ones and lo= cal to the LAN. These addresses can be overlapping between LANs and are not= useful to identify a target based on destination IP address.=20=20 but for call home we say you have to use > internal addresses.=20 Med: The addresses assigned by the CGN may not be visible locally while thi= s information is available for the call home DOTS client. Providing an exte= rnal IP @ + port number to the Call Home DOTS server won't be useful to det= ermine the internal IP address + internal port number. In the base signal channel we also said that we > did not give recommendations on how to discover possible translator > mechanisms... Med: We need to demonstrate that it is possible to provide useful informati= on that will be used to identify the attack source.=20 >=20 > To that aim, the Call Home DOTS client SHOULD rely on mechanisms, > such as [RFC8512] or [RFC8513], to retrieve the internal IP > address >=20 > ... yet here we seem to be making such recommendations! Med: For the reasons mentioned above.=20 >=20 > If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in > the > provider's domain to service its customers, the identification of > an > attack source bound to an IPv4 address/prefix MUST also rely on > source port numbers because the same IPv4 address is assigned to > multiple customers. The port information is required to > unambiguously identify the source of an attack. >=20 > [same question about how to know that they are in use] Med: Same answer :-) >=20 > If a translator is enabled on the boundaries of the domain > hosting > the Call Home DOTS server (e.g., a CPE with NAT enabled as shown > in > Figures 11 and 12), the Call Home DOTS server uses the attack > traffic > information conveyed in a mitigation request to find the internal > source IP address of the compromised device and blocks the > traffic >=20 > In a similar vein, I expect to get some questions about how the call > home DOTS server finds the internal source IP address from the > attack traffic information conveyed.=20 Med: because it is collocated with the NAT function and can thus proceed wi= th lookup on the NAT table.=20 I don't have a specific change > to propose at this time, since I don't know, myself, but we should > at least have some answer to give in response to such questions. >=20 > The text is also a little unclear on why we provide both Figures 11 > and > 12 -- while both cases are valid, we don't seem to have any > discussion that highlights differences between the cases. Med: Figure 10 is about a provider that controls both the CGN and the Call = Home DOTS Client, while Figure 11 is focusing more on NAT considerations at= attack source.=20 So > perhaps we should say that the behavior of the call home DOTS server > is the same whether or not the call home DOTS server is integrated > with the CPE/NAT (if true)? Med: This is not that true. The presence of a NAT at the attack source requ= ires additional processing to identify the source and enforce appropriate a= ctions.=20 >=20 > Section 3.3.3 >=20 > I think the YANG module might benefit from being moved up a level or > two in the section hierarchy. Med: OK. >=20 > Section 3.3.3.1 >=20 > Should we give some indication that 'signal' is the import prefix > for "ietf-dots-signal-channel" before going into the tree diagram? > (I do not know what the convention is in this regard.) Med: We can add it a mention.=20 >=20 > Section 3.3.3.2 >=20 > I suggest reiterating the note from 8782 about needing to check the > mapping output provided by YANG-to-CBOR in light of the situations > where differing CBOR/JSON types can arise (e.g., enumerations and > 64-bit quantities). Med: OK >=20 > I guess it's implicit that we reuse the CBOR map keys 8 and 9 for > lower-port and upper-port in the source-port-range array? Med: Yes.=20 >=20 > Section 3.3.3.3 >=20 > This module uses the common YANG types defined in [RFC6991] and > the > data structure defined in [RFC8791]. >=20 > (nit) I think we need another word here, maybe "data structure > extension" or "data structure statement"? Med: OK for "extension" >=20 > list source-icmp-type-range { > key "lower-type"; > description > "ICMP type range. When only lower-type is > present, it represents a single ICMP type."; >=20 > It seems that the interpretation of the source-icmp-type-range list > is dependent on the IP address family in use. Med: Yes.=20 Presumably one is > supposed to infer this from the source-prefix Med: It is inferred from the target-prefix (which is mandatory). (though we don't say > so), but the source-prefix is optional when these fields are used in > the base signal channel. It is not entirely clear whether it is > safe to rely on the target-prefix for address-family determination, > though (I do not recall any reason why DOTS signal channel doesn't > work in the presence of a NAPT function). Should the icmp > attributes only be allowed if the source-prefix is present? >=20 > sx:augment-structure "/signal:dots-signal/signal:message-type/" > + "signal:redirected-signal" { > description > "The alternate Call Home DOTS client."; >=20 > Is there something we can/should do for the redirected-signal > augmentation to indicate that the alt-server and alt-server-record > nodes are removed/useless? Med: We do have the following in the bis: | +--:(server-to-client-only) | +-- alt-server string | +-- alt-server-record* inet:ip-address And in the following in this draft:=20 +--:(call-home-only) +-- alt-ch-client? string +-- alt-ch-client-record* inet:ip-address +-- ttl? uint32 But we can add some text to restate this.=20 >=20 > leaf alt-ch-client { > type string; > description > "FQDN of an alternate Call Home DOTS client."; >=20 > Can we discuss a bit what the implications of redirection are for > (D)TLS mutual authentication of the post-redirection channel? It > seems that in most cases the alt-ch-client FQDN will be needed to > perform certificate validation. Perhaps, though, there would be a > case where a call home server has a set of preconfigured call home > clients (each with IP > address(es) and credentials), so a redirection by IP address to a > different client in that set would still be functional. So, I am > not sure that we need to make alt-ch-client a mandatory field > (whether in the YANG or in the prose), but we probably do need to > have some text earlier in the document covering the implications for > authenticating the redirected-to peer. I note that in the base > signal channel, alt-server is mandatory, so we would have some > precendent for just making als-ch-client mandatory as well. >=20 Med: As you can read in the NEW text above, alt-ch-client is mandatory for = the same reasons as in the base spec: certificate validation.=20=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 14 06:38: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 C8F2B3A0D87; Wed, 14 Oct 2020 06:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QugRsvukb9DT; Wed, 14 Oct 2020 06:38:05 -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 1E1DF3A0DD5; Wed, 14 Oct 2020 06:37:37 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4CBD4H3d7mz20Fd; Wed, 14 Oct 2020 15:37:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602682655; bh=+d7Z5B3Xe4pn91ISn8aHlYISelM73IKD6qAVFD/JK4g=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GR73eLPeGBZVletSOoZ8MGsh9/6Z31oHEbE2F+aARwU9dxfLQXY1xKrfVak6D3LZR kHfmzKFRD6HaU5XBWx3s0stJUQwmJyYZ0qCy+HsULgJXV37aZIC9L1abuDs1nFmNSS cXe2IoT7ga8v85aw+gL0pibNxOmSpU69fzpoOJEzdNpo7wt1KyRS+V2AuAhtgI0rAr QTmMB42rVeXyyKTg9MR5oabvcQIyhjwT2DZfIIhrrw4dqPrLT+zwH1TNZRhCTRfAUB CGrs9QbKvZVGbtWBa8JTv0tx6aY+ewlI6B8cQ11XMmbT71E/rPPfD6AotjbgjtWlpG fyi/JueSE0uXw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4CBD4H2b9mzyQV; Wed, 14 Oct 2020 15:37:35 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-call-home.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: AD evaluation of draft-ietf-dots-signal-call-home-09: Section 4 Thread-Index: AdaiLynBwFg+y+Y2RniAFXLwailOPw== Date: Wed, 14 Oct 2020 13:37:34 +0000 Message-ID: <6907_1602682655_5F86FF1F_6907_180_1_787AE7BB302AE849A7480A190F8B933031560086@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 4 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, 14 Oct 2020 13:38:07 -0000 Re-,=20 Please see inline.=20 Cheers, Med >=20 > Section 4.2 >=20 > Table 2 doesn't seem consistent with Table 1 -- Table 1 lists a > couple parameters that admit multiple CBOR types, but Table 2 only > lists a single CBOR Major Type for them. [Med] There is only one major type for the new attributes in both tables. T= he other type in table 1 is for the internal item. This is how we handled t= his in 8782.=20=20=20 >=20 > Section 4.3 >=20 > We don't have any visible note about removing TBA9 (and should > probably add some text about 4 only being the *requested* value as > well, though I'm pretty sure we'd know if there were other Standards > Actions in the works that would be potentially requesting a > conflicting value!). [Med] Will add the note.=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 14 07:38: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 22AE83A0E10; Wed, 14 Oct 2020 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqr4cxSqNCFg; Wed, 14 Oct 2020 07:38: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 4ABF33A0DE4; Wed, 14 Oct 2020 07:38:17 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4CBFQJ0Rh1z2ybn; Wed, 14 Oct 2020 16:38:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602686296; bh=JHw/xRfJ7sHOGbcMPfuq9n1E3aTBTsE0sPpJln9Q/Gs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=tbuT6bQuaadSzJ84iS7SNCkKa4sZnHQkniB8ExcBhg92g6CZdpi/85eh4bMZ1MIO+ pFI3h866yg1JyTf++eytpAbtTVHzfVIfnEcjuQ+zfazPKAICHSs2PEkKw1oUiyUeGX NNUPftZXJ5v03K4yTqFnYbViaGu4bd/R/xzau4welIaBCJW0EewRzpfuROPyoynkhN AKw6F7dd3UOKI6hp8nVrhCDy29WPdlFOFj22JNkYKl8WTz2RHc1IVVZ3e98v7sJZdk OITu2VSqSdvlo1mh5g/DKlfRYmcZkT9WjRZGlsynpSACEGE2bPsq5K+OsuafIUvOmg 0d6FCqIHfHXFw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4CBFQH6b4jz1xns; Wed, 14 Oct 2020 16:38:15 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-call-home.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: AD evaluation of draft-ietf-dots-signal-call-home-09: Section 5 Thread-Index: AdaiN6P/UmNlY8EdTcOvtwPq4fv7mA== Date: Wed, 14 Oct 2020 14:38:15 +0000 Message-ID: <10675_1602686295_5F870D57_10675_35_2_787AE7BB302AE849A7480A190F8B93303156014A@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 5 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, 14 Oct 2020 14:38:19 -0000 Re-, Please see inline.=20 Cheers, Med >=20 > Section 5 >=20 > We should probably say something about how the the call home channel > is a potential vector for attack, with mitigation requests > potentially causing the indicated device to be partially blocked or > booted off the network entirely; mutual authentication of a trusted > call home server, "a healthy dose of skepticism about the indicated > attack" (or rather, local inspection of the indicated traffic), and > involvement of the local administrator can mitigate the new risks > that are opened up. > This is related to what we currently have in the last paragraph, but > we don't specifically discuss it as a new risk/attack vector due to > this protocol. [Med] Add this NEW text: The DOTS Call Home can be misused by a misbehaving Call Home DOTS client by arbitrary signalling legitimate traffic as being attack traffic, or falsifying mitigation signals so that some sources are disconnected or some traffic is rate-limited... >=20 > We might also consider referencing the security considerations of > RFC > 8071 (NETCONF/RESTCONF call home) since the "considerations not > associated with server authentication" are likely similar. [Med] The only paragraph that can apply is the one related to computation. = That one is already echoed in the document. The one about scanning does not apply as connections always at the initiati= ve of the server. >=20 > There may also be some considerations when the indicated attack > source-prefix is in a private or local-use address range -- the "in > scope" check at the call home server doesn't mean much. [Med] Added this text right after the NEW one provided above: ... Such misbehaving Call Home DOTS clients may include sources identified by IP addresses that are used for internal use only (that is, these addresses are not visible outside a Call Home DOTS server domain). Such requests should be discarded by the Call Home DOTS server. More generally, Call Home DOTS servers should not blindly trust mitigation requests from Call Home DOTS clients.... >=20 > Common precautions mitigating DoS attacks are recommended, such > as > temporarily blacklisting the source address after a set number of > unsuccessful authentication attempts. >=20 > [I note that we used the term "drop-list" in RFC 8783.] [Med] Indeed. Fixed.=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 14 09:12:45 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C013A097A for ; Wed, 14 Oct 2020 09:12: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 WB-gbAXYM09P for ; Wed, 14 Oct 2020 09:12:40 -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 5809D3A0967 for ; Wed, 14 Oct 2020 09:12: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 1kSjOG-000210-Fx; Wed, 14 Oct 2020 17:12:36 +0100 From: To: , "'Benjamin Kaduk'" , Cc: References: <23440_1602682045_5F86FCBD_23440_36_1_787AE7BB302AE849A7480A190F8B933031560069@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <23440_1602682045_5F86FCBD_23440_36_1_787AE7BB302AE849A7480A190F8B933031560069@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 14 Oct 2020 17:12:31 +0100 Message-ID: <08fb01d6a244$d1c47f80$754d7e80$@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: AQGYB6taMR4VFnvUQ0H11VQ5e0RT6qoUTSTw Content-Language: en-gb Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 16:12:44 -0000 Hi All, See inline Jon> Regards Jon > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 14 October 2020 14:27 > To: Benjamin Kaduk; draft-ietf-dots-signal-call-home.all@ietf.org > Cc: dots@ietf.org > Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: > Section 3 > > Re- > > Please see inline. > > Cheers, > Med > > > remains the same. Furthermore, existing certificate chains and > > mutual authentication mechanisms between the DOTS agents are > > unaffected by the Call Home function. This Call Home function > > > > This may merit a bit more text, or at least a bit more thought, > > since we are now asking the certificate validation to be used for a > > different logical purpose. While it's true that the entity acting > > as a (D)TLS server is likely to be the same device as a regular DOTS > > server (or at least operated by the same DMS provider), and so there > > is a fairly strong analogue there in terms of the (D)TLS server > > certificate validation procedures, the (D)TLS client is something of > > a different entity than a traditional DOTS client. It's true that > > RFC 8782 leaves the specifics of the mutual authentication a bit > > under-specified (and essentially just says that it has to happen > > somehow), but one might imagine that the number of DOTS clients are > > fairly small and tied to specific legal contracts, so manual > > provisioning (or provisioning during > > onboarding) of client certificate information is reasonable. For > > the call home case, we should expect a lot more call home DOTS > > servers (i.e., (D)TLS clients) and thus should probably have a > > better story for automating the mutual authentication check. > > Defining an extendedKeyUsage value that indicate authorization to > > act as a call home server would be one typical way to do so (it's > > perhaps unfortunate that we didn't define an EKU for DOTS client > > usage), but if we're not going to do that we should at least put > > some words in about how the mutual authentication requirement > > remains but a different ACL may be needed for call home than for > > traditional DOTS sessions. > > Med: I admit that I don't see a difference between the two. I let Tiru and Jon > share their views on this. Jon> The DOTS server can control which DOTS clients are allowed to connect to it (by IP, PKI mutual trust, PKI SubjectAltName, PKI CN, CUID immediately come to mind). To me EKU could be useful, but I cannot put a great deal of trust in it. Jon> I don't really see any difference here with how the Call Home DOTS client determines which Call Home DOTS server is allowed to contact it at the (D)TLS level - other than handling the potential scale of numbers of the Call Home DOTS clients. A bigger challenge that I see is how the Call Home DOTS client knows (i.e. is configured in a trusted way) which Call Home DOTS server is responsible for which set of source addresses that the attacks are actually coming from. However, I do agree that DOTs client are more likely have a legal framework in place (if you want to use my DDoS mitigation service you must do ....), but it is in the Call Home DOTS client interest to have as many Call Home DOTS servers in place that can be used to mitigate DDoS attacks coming from the Call Home DOTS server environment - but those users will not care as much as they are less likely to be affected. > > > > > enables the DOTS server co-located with a network element > > (possibly > > > > (Still Call Home server, right?) > > Med: Yes. Update the text for better clarity: > > This Call Home function enables the Call Home DOTS server > co-located with a network element (possibly behind NATs and > firewalls) reachable by only the intended Call Home DOTS client and > hence the Call Home DOTS server cannot be subjected to these DDoS > attacks. > > > > > Section 3.2.1 > > > > If the Call Home DOTS server does not receive any traffic from > > the > > peer Call Home DOTS client during the time span required to > > exhaust > > the maximum 'missing-hb-allowed' threshold, the Call Home DOTS > > server > > concludes the session is disconnected. Then, the Call Home DOTS > > server MUST try to resume the (D)TLS session. > > > > Why resume specifically, as opposed to the broader "initate a new > > (D)TLS connection" that could encompass both resumption and a full > > handshake? > > [Med] A new connection will be used if resumption fails. This is handled by > the DTLS layer. > > Jon, can please confirm/infirm this how your implementation works? > Thanks. Jon> As it happens, the CoAP library I use (libcoap) does not instruct the TLS library (OpenSSL in my case) to try to do session resumption and keep the returned Session IDs to be able to do a resume. This is something that I have been thinking about adding to libcoap. Jon> So, in my case, if a session fails, the logic starts up a new connection with all its associated overheads. ~Jon > > > > > Section 3.2.2 > > > > If a Call Home DOTS client wants to redirect a Call Home DOTS > > server > > to another Call Home DOTS client, it MUST send a Non-confirmable > > PUT > > request to the predefined resource ".well-known/dots/redirect" > > with > > the new Call Home DOTS client FQDN or IP address in the body of > > the > > PUT similar to what is described in Section 4.6 of > > [I-D.ietf-dots-rfc8782-bis]. [...] > > > > I suggest that we mention the actual element in the YANG module that > > contains the structure that will be used as the PUT body, as this > > text in isolation feels like it's attempting to define the protocol > > by way of example and analogy, which is not a great pattern for > > protocol design. > > [Med] Fair comment. Added this new text: > > the following attributes in the body of the PUT request: > > alt-ch-client: The FQDN of an alternate Call Home DOTS client. > > This is a mandatory attribute for DOTS signal Call Home. It MUST > NOT be used for base DOTS signal channel operations. > > alt-ch-client-record: List of records for the alternate Call Home > DOTS client. > > This is an optional attribute for DOTS signal Call Home. It MUST > NOT be used for base DOTS signal channel operations. > > ttl: The Time to live (TTL) of the alternate Call Home DOTS client. > That is, the time interval that the alternate Call Home DOTS > client may be cached for use by a Call Home DOTS server. > > This is an optional attribute for DOTS signal Call Home. It MUST > NOT be used for base DOTS signal channel operations. > > > > > Section 3.3.1 > > > > > > In > > addition, the DOTS client MUST validate that attacker prefixes > > are > > within the scope of the DOTS server domain. > > > > What does "within the scope" mean in the context of the base signal > > channel? > > [Med] The analogy with the base signal channel is to make sure that the IP > resources are associated with the DOTS client domain. For the call home > case, these resources must be bound to the call home dots server domain. > > > > > (i.e., the Call Home scenario depicted in Figure 7). The > > 'target- > > uri' or 'target-fqdn' parameters can be included in a mitigation > > request for diagnostic purposes to notify the Call Home DOTS > > server > > domain administrator, but SHOULD NOT be used to determine the > > target > > IP addresses. Note that 'target-prefix' becomes a mandatory > > attribute in the mitigation request signaling the attack > > information > > because 'target-uri' and 'target-fqdn' are optional attributes > > and > > 'alias-name' will not be conveyed in a mitigation request. > > > > I think we have to use normative language that 'target-prefix' is > > mandatory for call home, since the "don't rely on target-fqdn or > > target-uri' is not a MUST. (Actually, I think they would have to be > > "MUST NOT send", not just "MUST NOT rely on for identification", in > > order for us to be able to get away with the current wording that > > states it like a fact.) > > [Med] I'm afraid this is redundant with RFC8782 that says: > > In the PUT request, at least one of the attributes 'target-prefix', > 'target-fqdn','target-uri', or 'alias-name' MUST be present. > > > > > Also, we might want to explain why 'alias-name' cannot be used (and > > we don't need normative language to ensure it): they are created > > using the data channel but there is no call home data channel (yet, > > at least). > > [Med] The target can be any address, not only those managed by a call home > DOTS client. Even if RESTCONF Call Home (RFC8071)+ DOTS Data Channel are > enabled, there is no viable use case for a call home DOTS client to create > aliases and for the server (a CPE, for example) to store them. > > I propose to change to "and 'alias-name' is unlikely to be conveyed in a > mitigation request.". > > Not sure if it is worth to add a note. > > > > > In order to help attack source identification by a Call Home DOTS > > server, the Call Home DOTS client SHOULD include in its > > mitigation > > request additional information such as 'source-port-range' or > > 'source-icmp-type-range'. The Call Home DOTS client may not > > include > > such information if 'source-prefix' conveys an IPv6 > > address/prefix. > > > > I'm not sure what the "may not" is intending to convey, here. > > [Med] This to say that an IPv6 address would be sufficient to identify an > internal host. > > Are > > these mandaroy for IPv4 prefixes? > > [Med] Because of the NAT, a singled source address may be shared. > Providing these additional attributes is recommended to hep identifying > the internal IP address. > > > > > The Call Home DOTS server MUST check that the 'source-prefix' is > > within the scope of the Call Home DOTS server domain. Note that > > in a > > > > (nit) this "MUST" seems redundant with the text I quoted previously. > > [Med] The first one was on the client side. This one at the server side. > > > > > The Call Home DOTS server MUST check that the 'source-prefix' is > > within the scope of the Call Home DOTS server domain. Note that > > in a > > DOTS Call Home scenario, the Call Home DOTS server considers, by > > default, that any routeable IP prefix enclosed in 'target-prefix' > > is > > within the scope of the Call Home DOTS client. [...] > > > > We say "by default" -- how would some other behavior be activated? > > [Med] local configuration. > > > > > with or without DOTS server domain administrator consent. If the > > attack traffic is blocked, the Call Home DOTS server informs the > > Call > > Home DOTS client that the attack is being mitigated. > > > > This is just a normal 2.xx response code (and body) to the > > mitigation request? It might be worth clarifying. > > Med: Fixed. > > > > > If the attack traffic information is identified by the Call Home > > DOTS > > server or the Call Home DOTS server domain administrator as > > legitimate traffic, the mitigation request is rejected, and 4.09 > > (Conflict) is returned to the Call Home DOTS client. The > > conflict- > > > > There may be quite some delay involved if the administrator needs to > > decide. Should we say more about (e.g.) using 5.03 and Max-Age in > > this case? > > Med: Already answer in the first part. > > > > > Once the request is validated by the Call Home DOTS server, > > appropriate actions are enforced to block the attack traffic > > within > > the source network. The Call Home DOTS client is informed about > > the > > progress of the attack mitigation following the rules in > > [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS > > server is embedded in a CPE, it can program the packet processor > > to > > punt all the traffic from the compromised device to the target to > > > > I think the sentence about "informed about the progress" might be > > misplaced at this location within the paragraph -- the example given > > seems to just be talking about the "appropriate actions" that are > > taken for blocking traffic, not any mitigation-status updates. > > Med: Rearranged the text accordingly. > > > > > Section 3.3.2 > > > > If a Carrier Grade NAT (CGN, including NAT64) is located between > > the > > DOTS client domain and DOTS server domain, communicating an > > external > > IP address in a mitigation request is likely to be discarded by > > the > > Call Home DOTS server because the external IP address is not > > visible > > locally to the Call Home DOTS server (see Figure 10). The Call > > Home > > DOTS server is only aware of the internal IP addresses/prefixes > > bound > > to its domain. Thus, the Call Home DOTS client MUST NOT include > > the > > external IP address and/or port number identifying the suspect > > attack > > source, but MUST include the internal IP address and/or port > > number. > > > > We're likely to get similar complaints about "how will they know > > there's a NAT" that we did for the base signal channel. I don't > > have any great suggestions for trying to forestall such comments, > > though I do note that > > 8782 has some explicit text about "[t]his document does not make any > > recommendations about possible translator discovery mechanisms". > > Med: The target deployment model is a service provider that want to > preserve the reputation of its network. The CGN and the Call Home DOTS > client are likely to be owned by that same SP. In such case, the information > about the presence of address sharing is given. > > > > > Also, it's amusing that for the base signal channel we said to *not* > > use internal addresses, > > Med: which is normal because the internal addresses are private ones and > local to the LAN. These addresses can be overlapping between LANs and are > not useful to identify a target based on destination IP address. > > but for call home we say you have to use > > internal addresses. > > Med: The addresses assigned by the CGN may not be visible locally while > this information is available for the call home DOTS client. Providing an > external IP @ + port number to the Call Home DOTS server won't be useful > to determine the internal IP address + internal port number. > > In the base signal channel we also said that we > > did not give recommendations on how to discover possible translator > > mechanisms... > > Med: We need to demonstrate that it is possible to provide useful > information that will be used to identify the attack source. > > > > > To that aim, the Call Home DOTS client SHOULD rely on mechanisms, > > such as [RFC8512] or [RFC8513], to retrieve the internal IP > > address > > > > ... yet here we seem to be making such recommendations! > > Med: For the reasons mentioned above. > > > > > If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in > > the > > provider's domain to service its customers, the identification of > > an > > attack source bound to an IPv4 address/prefix MUST also rely on > > source port numbers because the same IPv4 address is assigned to > > multiple customers. The port information is required to > > unambiguously identify the source of an attack. > > > > [same question about how to know that they are in use] > > Med: Same answer :-) > > > > > If a translator is enabled on the boundaries of the domain > > hosting > > the Call Home DOTS server (e.g., a CPE with NAT enabled as shown > > in > > Figures 11 and 12), the Call Home DOTS server uses the attack > > traffic > > information conveyed in a mitigation request to find the internal > > source IP address of the compromised device and blocks the > > traffic > > > > In a similar vein, I expect to get some questions about how the call > > home DOTS server finds the internal source IP address from the > > attack traffic information conveyed. > > Med: because it is collocated with the NAT function and can thus proceed > with lookup on the NAT table. > > I don't have a specific change > > to propose at this time, since I don't know, myself, but we should > > at least have some answer to give in response to such questions. > > > > The text is also a little unclear on why we provide both Figures 11 > > and > > 12 -- while both cases are valid, we don't seem to have any > > discussion that highlights differences between the cases. > > Med: Figure 10 is about a provider that controls both the CGN and the Call > Home DOTS Client, while Figure 11 is focusing more on NAT considerations > at attack source. > > So > > perhaps we should say that the behavior of the call home DOTS server > > is the same whether or not the call home DOTS server is integrated > > with the CPE/NAT (if true)? > > Med: This is not that true. The presence of a NAT at the attack source > requires additional processing to identify the source and enforce > appropriate actions. > > > > > Section 3.3.3 > > > > I think the YANG module might benefit from being moved up a level or > > two in the section hierarchy. > > Med: OK. > > > > > Section 3.3.3.1 > > > > Should we give some indication that 'signal' is the import prefix > > for "ietf-dots-signal-channel" before going into the tree diagram? > > (I do not know what the convention is in this regard.) > > Med: We can add it a mention. > > > > > Section 3.3.3.2 > > > > I suggest reiterating the note from 8782 about needing to check the > > mapping output provided by YANG-to-CBOR in light of the situations > > where differing CBOR/JSON types can arise (e.g., enumerations and > > 64-bit quantities). > > Med: OK > > > > > I guess it's implicit that we reuse the CBOR map keys 8 and 9 for > > lower-port and upper-port in the source-port-range array? > > Med: Yes. > > > > > Section 3.3.3.3 > > > > This module uses the common YANG types defined in [RFC6991] and > > the > > data structure defined in [RFC8791]. > > > > (nit) I think we need another word here, maybe "data structure > > extension" or "data structure statement"? > > Med: OK for "extension" > > > > > list source-icmp-type-range { > > key "lower-type"; > > description > > "ICMP type range. When only lower-type is > > present, it represents a single ICMP type."; > > > > It seems that the interpretation of the source-icmp-type-range list > > is dependent on the IP address family in use. > > Med: Yes. > > Presumably one is > > supposed to infer this from the source-prefix > > Med: It is inferred from the target-prefix (which is mandatory). > > (though we don't say > > so), but the source-prefix is optional when these fields are used in > > the base signal channel. It is not entirely clear whether it is > > safe to rely on the target-prefix for address-family determination, > > though (I do not recall any reason why DOTS signal channel doesn't > > work in the presence of a NAPT function). Should the icmp > > attributes only be allowed if the source-prefix is present? > > > > sx:augment-structure "/signal:dots-signal/signal:message-type/" > > + "signal:redirected-signal" { > > description > > "The alternate Call Home DOTS client."; > > > > Is there something we can/should do for the redirected-signal > > augmentation to indicate that the alt-server and alt-server-record > > nodes are removed/useless? > > Med: We do have the following in the bis: > > | +--:(server-to-client-only) > | +-- alt-server string > | +-- alt-server-record* inet:ip-address > > And in the following in this draft: > > +--:(call-home-only) > +-- alt-ch-client? string > +-- alt-ch-client-record* inet:ip-address > +-- ttl? uint32 > > But we can add some text to restate this. > > > > > leaf alt-ch-client { > > type string; > > description > > "FQDN of an alternate Call Home DOTS client."; > > > > Can we discuss a bit what the implications of redirection are for > > (D)TLS mutual authentication of the post-redirection channel? It > > seems that in most cases the alt-ch-client FQDN will be needed to > > perform certificate validation. Perhaps, though, there would be a > > case where a call home server has a set of preconfigured call home > > clients (each with IP > > address(es) and credentials), so a redirection by IP address to a > > different client in that set would still be functional. So, I am > > not sure that we need to make alt-ch-client a mandatory field > > (whether in the YANG or in the prose), but we probably do need to > > have some text earlier in the document covering the implications for > > authenticating the redirected-to peer. I note that in the base > > signal channel, alt-server is mandatory, so we would have some > > precendent for just making als-ch-client mandatory as well. > > > > Med: As you can read in the NEW text above, alt-ch-client is mandatory for > the same reasons as in the base spec: certificate validation. > > > ___________________________________________________________________ > ______________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Oct 14 14:44: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 3F4953A08E3; Wed, 14 Oct 2020 14:44:16 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WxLAJLhuGLWK; Wed, 14 Oct 2020 14:44:14 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 89B743A08C1; Wed, 14 Oct 2020 14:44:14 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09ELi7BX031556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 17:44:12 -0400 Date: Wed, 14 Oct 2020 14:44:06 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "draft-ietf-dots-signal-call-home.all@ietf.org" , "dots@ietf.org" Message-ID: <20201014214406.GT50845@kduck.mit.edu> References: <6907_1602682655_5F86FF1F_6907_180_1_787AE7BB302AE849A7480A190F8B933031560086@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6907_1602682655_5F86FF1F_6907_180_1_787AE7BB302AE849A7480A190F8B933031560086@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 4 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, 14 Oct 2020 21:44:16 -0000 On Wed, Oct 14, 2020 at 01:37:34PM +0000, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > > > > > Section 4.2 > > > > Table 2 doesn't seem consistent with Table 1 -- Table 1 lists a > > couple parameters that admit multiple CBOR types, but Table 2 only > > lists a single CBOR Major Type for them. > > [Med] There is only one major type for the new attributes in both tables. The other type in table 1 is for the internal item. This is how we handled this in 8782. Ah, I see now. (I did look at 8782, but apparently only at the YANG/JSON mapping table, not the IANA considerations.) Sorry for the confusion. > > > > Section 4.3 > > > > We don't have any visible note about removing TBA9 (and should > > probably add some text about 4 only being the *requested* value as > > well, though I'm pretty sure we'd know if there were other Standards > > Actions in the works that would be potentially requesting a > > conflicting value!). > > [Med] Will add the note. Thanks! -Ben From nobody Wed Oct 14 16:25: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 E2A5F3A1136; Wed, 14 Oct 2020 16:25:29 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lrbi1pZy7vy3; Wed, 14 Oct 2020 16:25:25 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7C4F83A1133; Wed, 14 Oct 2020 16:25:24 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09ENPHjf030034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 19:25:22 -0400 Date: Wed, 14 Oct 2020 16:25:17 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "draft-ietf-dots-signal-call-home.all@ietf.org" , "dots@ietf.org" Message-ID: <20201014232517.GU50845@kduck.mit.edu> References: <10675_1602686295_5F870D57_10675_35_2_787AE7BB302AE849A7480A190F8B93303156014A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10675_1602686295_5F870D57_10675_35_2_787AE7BB302AE849A7480A190F8B93303156014A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 5 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, 14 Oct 2020 23:25:30 -0000 Hi Med, Also inline. On Wed, Oct 14, 2020 at 02:38:15PM +0000, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > > > > > Section 5 > > > > We should probably say something about how the the call home channel > > is a potential vector for attack, with mitigation requests > > potentially causing the indicated device to be partially blocked or > > booted off the network entirely; mutual authentication of a trusted > > call home server, "a healthy dose of skepticism about the indicated > > attack" (or rather, local inspection of the indicated traffic), and > > involvement of the local administrator can mitigate the new risks > > that are opened up. > > This is related to what we currently have in the last paragraph, but > > we don't specifically discuss it as a new risk/attack vector due to > > this protocol. > > [Med] Add this NEW text: > > The DOTS Call Home can be misused by a misbehaving Call Home DOTS > client by arbitrary signalling legitimate traffic as being attack (nit) "arbitrarily", I think > traffic, or falsifying mitigation signals so that some sources are > disconnected or some traffic is rate-limited... > > > > > We might also consider referencing the security considerations of > > RFC > > 8071 (NETCONF/RESTCONF call home) since the "considerations not > > associated with server authentication" are likely similar. > > [Med] The only paragraph that can apply is the one related to computation. That one is already echoed in the document. > The one about scanning does not apply as connections always at the initiative of the server. Thanks for checking! > > > > There may also be some considerations when the indicated attack > > source-prefix is in a private or local-use address range -- the "in > > scope" check at the call home server doesn't mean much. > > [Med] Added this text right after the NEW one provided above: > > ... Such misbehaving Call > Home DOTS clients may include sources identified by IP addresses that > are used for internal use only (that is, these addresses are not > visible outside a Call Home DOTS server domain). Such requests > should be discarded by the Call Home DOTS server. More generally, > Call Home DOTS servers should not blindly trust mitigation requests > from Call Home DOTS clients.... I like this (especially the last sentence), but can we check that purely internal address cannot ever be the source of an attack (even in the presence of, e.g., NAT)? It is not intuitively obvious to me that always discarding such mitigation requests is the right thing. > > > > Common precautions mitigating DoS attacks are recommended, such > > as > > temporarily blacklisting the source address after a set number of > > unsuccessful authentication attempts. > > > > [I note that we used the term "drop-list" in RFC 8783.] > > [Med] Indeed. Fixed. Thanks! -Ben From nobody Wed Oct 14 17:20: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 2DA933A117D; Wed, 14 Oct 2020 17:20:44 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iuHlXqG_hLvF; Wed, 14 Oct 2020 17:20:41 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A4CFF3A117C; Wed, 14 Oct 2020 17:20:40 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09F0KWtr012554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 20:20:37 -0400 Date: Wed, 14 Oct 2020 17:20:32 -0700 From: Benjamin Kaduk To: supjps-ietf@jpshallow.com Cc: mohamed.boucadair@orange.com, draft-ietf-dots-signal-call-home.all@ietf.org, dots@ietf.org Message-ID: <20201015002032.GW50845@kduck.mit.edu> References: <23440_1602682045_5F86FCBD_23440_36_1_787AE7BB302AE849A7480A190F8B933031560069@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <08fb01d6a244$d1c47f80$754d7e80$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08fb01d6a244$d1c47f80$754d7e80$@jpshallow.com> Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 00:20:44 -0000 Hi Jon, Med, Also inline. On Wed, Oct 14, 2020 at 05:12:31PM +0100, supjps-ietf@jpshallow.com wrote: > Hi All, > > See inline Jon> > > Regards > > Jon > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > > Sent: 14 October 2020 14:27 > > To: Benjamin Kaduk; draft-ietf-dots-signal-call-home.all@ietf.org > > Cc: dots@ietf.org > > Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: > > Section 3 > > > > Re- > > > > Please see inline. > > > > Cheers, > > Med > > > > > remains the same. Furthermore, existing certificate chains and > > > mutual authentication mechanisms between the DOTS agents are > > > unaffected by the Call Home function. This Call Home function > > > > > > This may merit a bit more text, or at least a bit more thought, > > > since we are now asking the certificate validation to be used for a > > > different logical purpose. While it's true that the entity acting > > > as a (D)TLS server is likely to be the same device as a regular DOTS > > > server (or at least operated by the same DMS provider), and so there > > > is a fairly strong analogue there in terms of the (D)TLS server > > > certificate validation procedures, the (D)TLS client is something of > > > a different entity than a traditional DOTS client. It's true that > > > RFC 8782 leaves the specifics of the mutual authentication a bit > > > under-specified (and essentially just says that it has to happen > > > somehow), but one might imagine that the number of DOTS clients are > > > fairly small and tied to specific legal contracts, so manual > > > provisioning (or provisioning during > > > onboarding) of client certificate information is reasonable. For > > > the call home case, we should expect a lot more call home DOTS > > > servers (i.e., (D)TLS clients) and thus should probably have a > > > better story for automating the mutual authentication check. > > > Defining an extendedKeyUsage value that indicate authorization to > > > act as a call home server would be one typical way to do so (it's > > > perhaps unfortunate that we didn't define an EKU for DOTS client > > > usage), but if we're not going to do that we should at least put > > > some words in about how the mutual authentication requirement > > > remains but a different ACL may be needed for call home than for > > > traditional DOTS sessions. > > > > Med: I admit that I don't see a difference between the two. I let Tiru and > Jon > > share their views on this. > > Jon> The DOTS server can control which DOTS clients are allowed to connect > to it (by IP, PKI mutual trust, PKI SubjectAltName, PKI CN, CUID > immediately come to mind). To me EKU could be useful, but I cannot put a > great deal of trust in it. > > Jon> I don't really see any difference here with how the Call Home DOTS > client determines which Call Home DOTS server is allowed to contact it at > the (D)TLS level - other than handling the potential scale of numbers of the > Call Home DOTS clients. I think it's important to mention the scale -- manual credential management is not going to work well here. If we have some possible solutions that can be mentioned as potential options for how to do this well, that would be ideal, but it is not required for the document to proceed > A bigger challenge that I see is how the Call Home DOTS client knows (i.e. > is configured in a trusted way) which Call Home DOTS server is responsible > for which set of source addresses that the attacks are actually coming from. True, this seems "easy" if the call home client is the ISP but pretty hard otherwise. Might be worth mentioning as well... > However, I do agree that DOTs client are more likely have a legal framework > in place (if you want to use my DDoS mitigation service you must do ....), > but it is in the Call Home DOTS client interest to have as many Call Home > DOTS servers in place that can be used to mitigate DDoS attacks coming from > the Call Home DOTS server environment - but those users will not care as > much as they are less likely to be affected. > > > > > > > > > enables the DOTS server co-located with a network element > > > (possibly > > > > > > (Still Call Home server, right?) > > > > Med: Yes. Update the text for better clarity: > > > > This Call Home function enables the Call Home DOTS server > > co-located with a network element (possibly behind NATs and > > firewalls) reachable by only the intended Call Home DOTS client and > > hence the Call Home DOTS server cannot be subjected to these DDoS > > attacks. > > > > > > > > Section 3.2.1 > > > > > > If the Call Home DOTS server does not receive any traffic from > > > the > > > peer Call Home DOTS client during the time span required to > > > exhaust > > > the maximum 'missing-hb-allowed' threshold, the Call Home DOTS > > > server > > > concludes the session is disconnected. Then, the Call Home DOTS > > > server MUST try to resume the (D)TLS session. > > > > > > Why resume specifically, as opposed to the broader "initate a new > > > (D)TLS connection" that could encompass both resumption and a full > > > handshake? > > > > [Med] A new connection will be used if resumption fails. This is handled > by > > the DTLS layer. > > > > Jon, can please confirm/infirm this how your implementation works? > > Thanks. > > Jon> As it happens, the CoAP library I use (libcoap) does not instruct the > TLS library (OpenSSL in my case) to try to do session resumption and keep > the returned Session IDs to be able to do a resume. This is something that > I have been thinking about adding to libcoap. > > Jon> So, in my case, if a session fails, the logic starts up a new > connection with all its associated overheads. Hmm, I think we should not use the term "resume" then, since it's a TLS term of art and the property that we really need is "have a new TLS connection" not "have a resumed TLS connection". If we can get a resumed one that is nice, and trying resumption first makes sense, but I don't think we can justify a MUST-level requirement. -Ben > > > > > > > > > Section 3.2.2 > > > > > > If a Call Home DOTS client wants to redirect a Call Home DOTS > > > server > > > to another Call Home DOTS client, it MUST send a Non-confirmable > > > PUT > > > request to the predefined resource ".well-known/dots/redirect" > > > with > > > the new Call Home DOTS client FQDN or IP address in the body of > > > the > > > PUT similar to what is described in Section 4.6 of > > > [I-D.ietf-dots-rfc8782-bis]. [...] > > > > > > I suggest that we mention the actual element in the YANG module that > > > contains the structure that will be used as the PUT body, as this > > > text in isolation feels like it's attempting to define the protocol > > > by way of example and analogy, which is not a great pattern for > > > protocol design. > > > > [Med] Fair comment. Added this new text: > > > > the following attributes in the body of the PUT request: > > > > alt-ch-client: The FQDN of an alternate Call Home DOTS client. > > > > This is a mandatory attribute for DOTS signal Call Home. It MUST > > NOT be used for base DOTS signal channel operations. > > > > alt-ch-client-record: List of records for the alternate Call Home > > DOTS client. > > > > This is an optional attribute for DOTS signal Call Home. It MUST > > NOT be used for base DOTS signal channel operations. > > > > ttl: The Time to live (TTL) of the alternate Call Home DOTS client. > > That is, the time interval that the alternate Call Home DOTS > > client may be cached for use by a Call Home DOTS server. > > > > This is an optional attribute for DOTS signal Call Home. It MUST > > NOT be used for base DOTS signal channel operations. > > > > > > > > Section 3.3.1 > > > > > > > > > In > > > addition, the DOTS client MUST validate that attacker prefixes > > > are > > > within the scope of the DOTS server domain. > > > > > > What does "within the scope" mean in the context of the base signal > > > channel? > > > > [Med] The analogy with the base signal channel is to make sure that the IP > > resources are associated with the DOTS client domain. For the call home > > case, these resources must be bound to the call home dots server domain. > > > > > > > > (i.e., the Call Home scenario depicted in Figure 7). The > > > 'target- > > > uri' or 'target-fqdn' parameters can be included in a mitigation > > > request for diagnostic purposes to notify the Call Home DOTS > > > server > > > domain administrator, but SHOULD NOT be used to determine the > > > target > > > IP addresses. Note that 'target-prefix' becomes a mandatory > > > attribute in the mitigation request signaling the attack > > > information > > > because 'target-uri' and 'target-fqdn' are optional attributes > > > and > > > 'alias-name' will not be conveyed in a mitigation request. > > > > > > I think we have to use normative language that 'target-prefix' is > > > mandatory for call home, since the "don't rely on target-fqdn or > > > target-uri' is not a MUST. (Actually, I think they would have to be > > > "MUST NOT send", not just "MUST NOT rely on for identification", in > > > order for us to be able to get away with the current wording that > > > states it like a fact.) > > > > [Med] I'm afraid this is redundant with RFC8782 that says: > > > > In the PUT request, at least one of the attributes 'target-prefix', > > 'target-fqdn','target-uri', or 'alias-name' MUST be present. > > > > > > > > Also, we might want to explain why 'alias-name' cannot be used (and > > > we don't need normative language to ensure it): they are created > > > using the data channel but there is no call home data channel (yet, > > > at least). > > > > [Med] The target can be any address, not only those managed by a call home > > DOTS client. Even if RESTCONF Call Home (RFC8071)+ DOTS Data Channel are > > enabled, there is no viable use case for a call home DOTS client to create > > aliases and for the server (a CPE, for example) to store them. > > > > I propose to change to "and 'alias-name' is unlikely to be conveyed in a > > mitigation request.". > > > > Not sure if it is worth to add a note. > > > > > > > > In order to help attack source identification by a Call Home DOTS > > > server, the Call Home DOTS client SHOULD include in its > > > mitigation > > > request additional information such as 'source-port-range' or > > > 'source-icmp-type-range'. The Call Home DOTS client may not > > > include > > > such information if 'source-prefix' conveys an IPv6 > > > address/prefix. > > > > > > I'm not sure what the "may not" is intending to convey, here. > > > > [Med] This to say that an IPv6 address would be sufficient to identify an > > internal host. > > > > Are > > > these mandaroy for IPv4 prefixes? > > > > [Med] Because of the NAT, a singled source address may be shared. > > Providing these additional attributes is recommended to hep identifying > > the internal IP address. > > > > > > > > The Call Home DOTS server MUST check that the 'source-prefix' is > > > within the scope of the Call Home DOTS server domain. Note that > > > in a > > > > > > (nit) this "MUST" seems redundant with the text I quoted previously. > > > > [Med] The first one was on the client side. This one at the server side. > > > > > > > > The Call Home DOTS server MUST check that the 'source-prefix' is > > > within the scope of the Call Home DOTS server domain. Note that > > > in a > > > DOTS Call Home scenario, the Call Home DOTS server considers, by > > > default, that any routeable IP prefix enclosed in 'target-prefix' > > > is > > > within the scope of the Call Home DOTS client. [...] > > > > > > We say "by default" -- how would some other behavior be activated? > > > > [Med] local configuration. > > > > > > > > with or without DOTS server domain administrator consent. If the > > > attack traffic is blocked, the Call Home DOTS server informs the > > > Call > > > Home DOTS client that the attack is being mitigated. > > > > > > This is just a normal 2.xx response code (and body) to the > > > mitigation request? It might be worth clarifying. > > > > Med: Fixed. > > > > > > > > If the attack traffic information is identified by the Call Home > > > DOTS > > > server or the Call Home DOTS server domain administrator as > > > legitimate traffic, the mitigation request is rejected, and 4.09 > > > (Conflict) is returned to the Call Home DOTS client. The > > > conflict- > > > > > > There may be quite some delay involved if the administrator needs to > > > decide. Should we say more about (e.g.) using 5.03 and Max-Age in > > > this case? > > > > Med: Already answer in the first part. > > > > > > > > Once the request is validated by the Call Home DOTS server, > > > appropriate actions are enforced to block the attack traffic > > > within > > > the source network. The Call Home DOTS client is informed about > > > the > > > progress of the attack mitigation following the rules in > > > [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS > > > server is embedded in a CPE, it can program the packet processor > > > to > > > punt all the traffic from the compromised device to the target to > > > > > > I think the sentence about "informed about the progress" might be > > > misplaced at this location within the paragraph -- the example given > > > seems to just be talking about the "appropriate actions" that are > > > taken for blocking traffic, not any mitigation-status updates. > > > > Med: Rearranged the text accordingly. > > > > > > > > Section 3.3.2 > > > > > > If a Carrier Grade NAT (CGN, including NAT64) is located between > > > the > > > DOTS client domain and DOTS server domain, communicating an > > > external > > > IP address in a mitigation request is likely to be discarded by > > > the > > > Call Home DOTS server because the external IP address is not > > > visible > > > locally to the Call Home DOTS server (see Figure 10). The Call > > > Home > > > DOTS server is only aware of the internal IP addresses/prefixes > > > bound > > > to its domain. Thus, the Call Home DOTS client MUST NOT include > > > the > > > external IP address and/or port number identifying the suspect > > > attack > > > source, but MUST include the internal IP address and/or port > > > number. > > > > > > We're likely to get similar complaints about "how will they know > > > there's a NAT" that we did for the base signal channel. I don't > > > have any great suggestions for trying to forestall such comments, > > > though I do note that > > > 8782 has some explicit text about "[t]his document does not make any > > > recommendations about possible translator discovery mechanisms". > > > > Med: The target deployment model is a service provider that want to > > preserve the reputation of its network. The CGN and the Call Home DOTS > > client are likely to be owned by that same SP. In such case, the > information > > about the presence of address sharing is given. > > > > > > > > Also, it's amusing that for the base signal channel we said to *not* > > > use internal addresses, > > > > Med: which is normal because the internal addresses are private ones and > > local to the LAN. These addresses can be overlapping between LANs and are > > not useful to identify a target based on destination IP address. > > > > but for call home we say you have to use > > > internal addresses. > > > > Med: The addresses assigned by the CGN may not be visible locally while > > this information is available for the call home DOTS client. Providing an > > external IP @ + port number to the Call Home DOTS server won't be useful > > to determine the internal IP address + internal port number. > > > > In the base signal channel we also said that we > > > did not give recommendations on how to discover possible translator > > > mechanisms... > > > > Med: We need to demonstrate that it is possible to provide useful > > information that will be used to identify the attack source. > > > > > > > > To that aim, the Call Home DOTS client SHOULD rely on mechanisms, > > > such as [RFC8512] or [RFC8513], to retrieve the internal IP > > > address > > > > > > ... yet here we seem to be making such recommendations! > > > > Med: For the reasons mentioned above. > > > > > > > > If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in > > > the > > > provider's domain to service its customers, the identification of > > > an > > > attack source bound to an IPv4 address/prefix MUST also rely on > > > source port numbers because the same IPv4 address is assigned to > > > multiple customers. The port information is required to > > > unambiguously identify the source of an attack. > > > > > > [same question about how to know that they are in use] > > > > Med: Same answer :-) > > > > > > > > If a translator is enabled on the boundaries of the domain > > > hosting > > > the Call Home DOTS server (e.g., a CPE with NAT enabled as shown > > > in > > > Figures 11 and 12), the Call Home DOTS server uses the attack > > > traffic > > > information conveyed in a mitigation request to find the internal > > > source IP address of the compromised device and blocks the > > > traffic > > > > > > In a similar vein, I expect to get some questions about how the call > > > home DOTS server finds the internal source IP address from the > > > attack traffic information conveyed. > > > > Med: because it is collocated with the NAT function and can thus proceed > > with lookup on the NAT table. > > > > I don't have a specific change > > > to propose at this time, since I don't know, myself, but we should > > > at least have some answer to give in response to such questions. > > > > > > The text is also a little unclear on why we provide both Figures 11 > > > and > > > 12 -- while both cases are valid, we don't seem to have any > > > discussion that highlights differences between the cases. > > > > Med: Figure 10 is about a provider that controls both the CGN and the Call > > Home DOTS Client, while Figure 11 is focusing more on NAT considerations > > at attack source. > > > > So > > > perhaps we should say that the behavior of the call home DOTS server > > > is the same whether or not the call home DOTS server is integrated > > > with the CPE/NAT (if true)? > > > > Med: This is not that true. The presence of a NAT at the attack source > > requires additional processing to identify the source and enforce > > appropriate actions. > > > > > > > > Section 3.3.3 > > > > > > I think the YANG module might benefit from being moved up a level or > > > two in the section hierarchy. > > > > Med: OK. > > > > > > > > Section 3.3.3.1 > > > > > > Should we give some indication that 'signal' is the import prefix > > > for "ietf-dots-signal-channel" before going into the tree diagram? > > > (I do not know what the convention is in this regard.) > > > > Med: We can add it a mention. > > > > > > > > Section 3.3.3.2 > > > > > > I suggest reiterating the note from 8782 about needing to check the > > > mapping output provided by YANG-to-CBOR in light of the situations > > > where differing CBOR/JSON types can arise (e.g., enumerations and > > > 64-bit quantities). > > > > Med: OK > > > > > > > > I guess it's implicit that we reuse the CBOR map keys 8 and 9 for > > > lower-port and upper-port in the source-port-range array? > > > > Med: Yes. > > > > > > > > Section 3.3.3.3 > > > > > > This module uses the common YANG types defined in [RFC6991] and > > > the > > > data structure defined in [RFC8791]. > > > > > > (nit) I think we need another word here, maybe "data structure > > > extension" or "data structure statement"? > > > > Med: OK for "extension" > > > > > > > > list source-icmp-type-range { > > > key "lower-type"; > > > description > > > "ICMP type range. When only lower-type is > > > present, it represents a single ICMP type."; > > > > > > It seems that the interpretation of the source-icmp-type-range list > > > is dependent on the IP address family in use. > > > > Med: Yes. > > > > Presumably one is > > > supposed to infer this from the source-prefix > > > > Med: It is inferred from the target-prefix (which is mandatory). > > > > (though we don't say > > > so), but the source-prefix is optional when these fields are used in > > > the base signal channel. It is not entirely clear whether it is > > > safe to rely on the target-prefix for address-family determination, > > > though (I do not recall any reason why DOTS signal channel doesn't > > > work in the presence of a NAPT function). Should the icmp > > > attributes only be allowed if the source-prefix is present? > > > > > > sx:augment-structure "/signal:dots-signal/signal:message-type/" > > > + "signal:redirected-signal" { > > > description > > > "The alternate Call Home DOTS client."; > > > > > > Is there something we can/should do for the redirected-signal > > > augmentation to indicate that the alt-server and alt-server-record > > > nodes are removed/useless? > > > > Med: We do have the following in the bis: > > > > | +--:(server-to-client-only) > > | +-- alt-server string > > | +-- alt-server-record* inet:ip-address > > > > And in the following in this draft: > > > > +--:(call-home-only) > > +-- alt-ch-client? string > > +-- alt-ch-client-record* inet:ip-address > > +-- ttl? uint32 > > > > But we can add some text to restate this. > > > > > > > > leaf alt-ch-client { > > > type string; > > > description > > > "FQDN of an alternate Call Home DOTS client."; > > > > > > Can we discuss a bit what the implications of redirection are for > > > (D)TLS mutual authentication of the post-redirection channel? It > > > seems that in most cases the alt-ch-client FQDN will be needed to > > > perform certificate validation. Perhaps, though, there would be a > > > case where a call home server has a set of preconfigured call home > > > clients (each with IP > > > address(es) and credentials), so a redirection by IP address to a > > > different client in that set would still be functional. So, I am > > > not sure that we need to make alt-ch-client a mandatory field > > > (whether in the YANG or in the prose), but we probably do need to > > > have some text earlier in the document covering the implications for > > > authenticating the redirected-to peer. I note that in the base > > > signal channel, alt-server is mandatory, so we would have some > > > precendent for just making als-ch-client mandatory as well. > > > > > > > Med: As you can read in the NEW text above, alt-ch-client is mandatory for > > the same reasons as in the base spec: certificate validation. > > > > > > ___________________________________________________________________ > > ______________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce > > message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete > > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > From nobody Wed Oct 14 19:14: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 E7DCC3A11E6; Wed, 14 Oct 2020 19:14:14 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BvUYDwm5MxNp; Wed, 14 Oct 2020 19:14:12 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C71C23A11E5; Wed, 14 Oct 2020 19:14:11 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09F2E3mJ013141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 22:14:09 -0400 Date: Wed, 14 Oct 2020 19:14:03 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "draft-ietf-dots-signal-call-home.all@ietf.org" , "dots@ietf.org" Message-ID: <20201015021403.GX50845@kduck.mit.edu> References: <23440_1602682045_5F86FCBD_23440_36_1_787AE7BB302AE849A7480A190F8B933031560069@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23440_1602682045_5F86FCBD_23440_36_1_787AE7BB302AE849A7480A190F8B933031560069@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 02:14:15 -0000 Hi Med, On Wed, Oct 14, 2020 at 01:27:24PM +0000, mohamed.boucadair@orange.com wrote: > Re- > > Please see inline. > > Cheers, > Med > > > remains the same. Furthermore, existing certificate chains and > > mutual authentication mechanisms between the DOTS agents are > > unaffected by the Call Home function. This Call Home function > > > > This may merit a bit more text, or at least a bit more thought, > > since we are now asking the certificate validation to be used for a > > different logical purpose. While it's true that the entity acting > > as a (D)TLS server is likely to be the same device as a regular DOTS > > server (or at least operated by the same DMS provider), and so there > > is a fairly strong analogue there in terms of the (D)TLS server > > certificate validation procedures, the (D)TLS client is something of > > a different entity than a traditional DOTS client. It's true that > > RFC 8782 leaves the specifics of the mutual authentication a bit > > under-specified (and essentially just says that it has to happen > > somehow), but one might imagine that the number of DOTS clients are > > fairly small and tied to specific legal contracts, so manual > > provisioning (or provisioning during > > onboarding) of client certificate information is reasonable. For > > the call home case, we should expect a lot more call home DOTS > > servers (i.e., (D)TLS clients) and thus should probably have a > > better story for automating the mutual authentication check. > > Defining an extendedKeyUsage value that indicate authorization to > > act as a call home server would be one typical way to do so (it's > > perhaps unfortunate that we didn't define an EKU for DOTS client > > usage), but if we're not going to do that we should at least put > > some words in about how the mutual authentication requirement > > remains but a different ACL may be needed for call home than for > > traditional DOTS sessions. > > Med: I admit that I don't see a difference between the two. I let Tiru and Jon share their views on this. > > > > > enables the DOTS server co-located with a network element > > (possibly > > > > (Still Call Home server, right?) > > Med: Yes. Update the text for better clarity: > > This Call Home function enables the Call Home DOTS server > co-located with a network element (possibly behind NATs and > firewalls) reachable by only the intended Call Home DOTS client and > hence the Call Home DOTS server cannot be subjected to these DDoS > attacks. Sure, thanks. A few nits fixed becomes: % This Call Home function enables a Call Home DOTS server % co-located with a network element (possibly behind NATs and % firewalls) to be reachable by only the intended Call Home DOTS client, and % hence the Call Home DOTS server cannot be subjected to such DDoS % attacks. > > > > Section 3.2.1 > > > > If the Call Home DOTS server does not receive any traffic from > > the > > peer Call Home DOTS client during the time span required to > > exhaust > > the maximum 'missing-hb-allowed' threshold, the Call Home DOTS > > server > > concludes the session is disconnected. Then, the Call Home DOTS > > server MUST try to resume the (D)TLS session. > > > > Why resume specifically, as opposed to the broader "initate a new > > (D)TLS connection" that could encompass both resumption and a full > > handshake? > > [Med] A new connection will be used if resumption fails. This is handled by the DTLS layer. > > Jon, can please confirm/infirm this how your implementation works? Thanks. > > > > > Section 3.2.2 > > > > If a Call Home DOTS client wants to redirect a Call Home DOTS > > server > > to another Call Home DOTS client, it MUST send a Non-confirmable > > PUT > > request to the predefined resource ".well-known/dots/redirect" > > with > > the new Call Home DOTS client FQDN or IP address in the body of > > the > > PUT similar to what is described in Section 4.6 of > > [I-D.ietf-dots-rfc8782-bis]. [...] > > > > I suggest that we mention the actual element in the YANG module that > > contains the structure that will be used as the PUT body, as this > > text in isolation feels like it's attempting to define the protocol > > by way of example and analogy, which is not a great pattern for > > protocol design. > > [Med] Fair comment. Added this new text: > > the following attributes in the body of the PUT request: > > alt-ch-client: The FQDN of an alternate Call Home DOTS client. > > This is a mandatory attribute for DOTS signal Call Home. It MUST > NOT be used for base DOTS signal channel operations. > > alt-ch-client-record: List of records for the alternate Call Home > DOTS client. > > This is an optional attribute for DOTS signal Call Home. It MUST > NOT be used for base DOTS signal channel operations. > > ttl: The Time to live (TTL) of the alternate Call Home DOTS client. > That is, the time interval that the alternate Call Home DOTS > client may be cached for use by a Call Home DOTS server. > > This is an optional attribute for DOTS signal Call Home. It MUST > NOT be used for base DOTS signal channel operations. Thanks, that helps a lot! > > > > Section 3.3.1 > > > > > > In > > addition, the DOTS client MUST validate that attacker prefixes > > are > > within the scope of the DOTS server domain. > > > > What does "within the scope" mean in the context of the base signal > > channel? > > [Med] The analogy with the base signal channel is to make sure that the IP resources are associated with the DOTS client domain. For the call home case, these resources must be bound to the call home dots server domain. Do you think that there is some text we could put in to give a hint about this? I worry that the usage for the base signal channel might be a bit subtle since we are making use of the role reversal. > > > > (i.e., the Call Home scenario depicted in Figure 7). The > > 'target- > > uri' or 'target-fqdn' parameters can be included in a mitigation > > request for diagnostic purposes to notify the Call Home DOTS > > server > > domain administrator, but SHOULD NOT be used to determine the > > target > > IP addresses. Note that 'target-prefix' becomes a mandatory > > attribute in the mitigation request signaling the attack > > information > > because 'target-uri' and 'target-fqdn' are optional attributes > > and > > 'alias-name' will not be conveyed in a mitigation request. > > > > I think we have to use normative language that 'target-prefix' is > > mandatory for call home, since the "don't rely on target-fqdn or > > target-uri' is not a MUST. (Actually, I think they would have to be > > "MUST NOT send", not just "MUST NOT rely on for identification", in > > order for us to be able to get away with the current wording that > > states it like a fact.) > > [Med] I'm afraid this is redundant with RFC8782 that says: > > In the PUT request, at least one of the attributes 'target-prefix', > 'target-fqdn','target-uri', or 'alias-name' MUST be present. I saw that part of 8782, but I did not see a "MUST NOT include 'target-fqdn' or 'target-uri'. So, the text from 8782 can be satisfied by having a (e.g.) 'target-fqdn' present and no 'target-prefix' or 'target-uri'; this document in turn says 'target-fqdn' "SHOULD NOT be used to determine the target attribute", which leaves us in a tough position. Better if we say straight-out that 'target-prefix' MUST be included for call home. > > > > Also, we might want to explain why 'alias-name' cannot be used (and > > we don't need normative language to ensure it): they are created > > using the data channel but there is no call home data channel (yet, > > at least). > > [Med] The target can be any address, not only those managed by a call home DOTS client. Even if RESTCONF Call Home (RFC8071)+ DOTS Data Channel are enabled, there is no viable use case for a call home DOTS client to create aliases and for the server (a CPE, for example) to store them. > > I propose to change to "and 'alias-name' is unlikely to be conveyed in a mitigation request.". > > Not sure if it is worth to add a note. I'm okay with just the change to 'unlikely'. Only if we definitively said "will not" do we need to explain why. (It's okay to explain why in other cases, too, but the explanation here is a bit complicated and might detract from the point we're trying to make.) > > > > In order to help attack source identification by a Call Home DOTS > > server, the Call Home DOTS client SHOULD include in its > > mitigation > > request additional information such as 'source-port-range' or > > 'source-icmp-type-range'. The Call Home DOTS client may not > > include > > such information if 'source-prefix' conveys an IPv6 > > address/prefix. > > > > I'm not sure what the "may not" is intending to convey, here. > > [Med] This to say that an IPv6 address would be sufficient to identify an internal host. > > Are > > these mandaroy for IPv4 prefixes? > > [Med] Because of the NAT, a singled source address may be shared. Providing these additional attributes is recommended to hep identifying the internal IP address. I made this comment because it seems like they might not be included for an IPv4 source-prefix, too, it's just that the likelihood of it is different. We could probbaly find a better phrasing for what we want to say, perhaps something like "IPv6 addresses/prefixes frequently serve to uniquely identify a network endpoint, without need for port or ICMP type information; while this is also possible for IPv4, it is much less often the case than for IPv6". > > > > The Call Home DOTS server MUST check that the 'source-prefix' is > > within the scope of the Call Home DOTS server domain. Note that > > in a > > > > (nit) this "MUST" seems redundant with the text I quoted previously. > > [Med] The first one was on the client side. This one at the server side. Ah, I missed that -- sorry! > > The Call Home DOTS server MUST check that the 'source-prefix' is > > within the scope of the Call Home DOTS server domain. Note that > > in a > > DOTS Call Home scenario, the Call Home DOTS server considers, by > > default, that any routeable IP prefix enclosed in 'target-prefix' > > is > > within the scope of the Call Home DOTS client. [...] > > > > We say "by default" -- how would some other behavior be activated? > > [Med] local configuration. > > > > > with or without DOTS server domain administrator consent. If the > > attack traffic is blocked, the Call Home DOTS server informs the > > Call > > Home DOTS client that the attack is being mitigated. > > > > This is just a normal 2.xx response code (and body) to the > > mitigation request? It might be worth clarifying. > > Med: Fixed. > > > > > If the attack traffic information is identified by the Call Home > > DOTS > > server or the Call Home DOTS server domain administrator as > > legitimate traffic, the mitigation request is rejected, and 4.09 > > (Conflict) is returned to the Call Home DOTS client. The > > conflict- > > > > There may be quite some delay involved if the administrator needs to > > decide. Should we say more about (e.g.) using 5.03 and Max-Age in > > this case? > > Med: Already answer in the first part. > > > > > Once the request is validated by the Call Home DOTS server, > > appropriate actions are enforced to block the attack traffic > > within > > the source network. The Call Home DOTS client is informed about > > the > > progress of the attack mitigation following the rules in > > [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS > > server is embedded in a CPE, it can program the packet processor > > to > > punt all the traffic from the compromised device to the target to > > > > I think the sentence about "informed about the progress" might be > > misplaced at this location within the paragraph -- the example given > > seems to just be talking about the "appropriate actions" that are > > taken for blocking traffic, not any mitigation-status updates. > > Med: Rearranged the text accordingly. Thanks. > > > > Section 3.3.2 > > > > If a Carrier Grade NAT (CGN, including NAT64) is located between > > the > > DOTS client domain and DOTS server domain, communicating an > > external > > IP address in a mitigation request is likely to be discarded by > > the > > Call Home DOTS server because the external IP address is not > > visible > > locally to the Call Home DOTS server (see Figure 10). The Call > > Home > > DOTS server is only aware of the internal IP addresses/prefixes > > bound > > to its domain. Thus, the Call Home DOTS client MUST NOT include > > the > > external IP address and/or port number identifying the suspect > > attack > > source, but MUST include the internal IP address and/or port > > number. > > > > We're likely to get similar complaints about "how will they know > > there's a NAT" that we did for the base signal channel. I don't > > have any great suggestions for trying to forestall such comments, > > though I do note that > > 8782 has some explicit text about "[t]his document does not make any > > recommendations about possible translator discovery mechanisms". > > Med: The target deployment model is a service provider that want to preserve the reputation of its network. The CGN and the Call Home DOTS client are likely to be owned by that same SP. In such case, the information about the presence of address sharing is given. > > > > > Also, it's amusing that for the base signal channel we said to *not* > > use internal addresses, > > Med: which is normal because the internal addresses are private ones and local to the LAN. These addresses can be overlapping between LANs and are not useful to identify a target based on destination IP address. > > but for call home we say you have to use > > internal addresses. > > Med: The addresses assigned by the CGN may not be visible locally while this information is available for the call home DOTS client. Providing an external IP @ + port number to the Call Home DOTS server won't be useful to determine the internal IP address + internal port number. > > In the base signal channel we also said that we > > did not give recommendations on how to discover possible translator > > mechanisms... > > Med: We need to demonstrate that it is possible to provide useful information that will be used to identify the attack source. > > > > > To that aim, the Call Home DOTS client SHOULD rely on mechanisms, > > such as [RFC8512] or [RFC8513], to retrieve the internal IP > > address > > > > ... yet here we seem to be making such recommendations! > > Med: For the reasons mentioned above. Okay. It seems like we are fairly well-prepared to field such questions as they arise, and it's not clear to me that trying to include such discussion in the text of the document is necessary. So let's leave this for now. (But maybe think about deployment scenarios other than the §1.1 ones?) > > > > If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in > > the > > provider's domain to service its customers, the identification of > > an > > attack source bound to an IPv4 address/prefix MUST also rely on > > source port numbers because the same IPv4 address is assigned to > > multiple customers. The port information is required to > > unambiguously identify the source of an attack. > > > > [same question about how to know that they are in use] > > Med: Same answer :-) > > > > > If a translator is enabled on the boundaries of the domain > > hosting > > the Call Home DOTS server (e.g., a CPE with NAT enabled as shown > > in > > Figures 11 and 12), the Call Home DOTS server uses the attack > > traffic > > information conveyed in a mitigation request to find the internal > > source IP address of the compromised device and blocks the > > traffic > > > > In a similar vein, I expect to get some questions about how the call > > home DOTS server finds the internal source IP address from the > > attack traffic information conveyed. > > Med: because it is collocated with the NAT function and can thus proceed with lookup on the NAT table. We don't require that deployment scenario, though; it's only the main expected one. > I don't have a specific change > > to propose at this time, since I don't know, myself, but we should > > at least have some answer to give in response to such questions. > > > > The text is also a little unclear on why we provide both Figures 11 > > and > > 12 -- while both cases are valid, we don't seem to have any > > discussion that highlights differences between the cases. > > Med: Figure 10 is about a provider that controls both the CGN and the Call Home DOTS Client, while Figure 11 is focusing more on NAT considerations at attack source. > > So > > perhaps we should say that the behavior of the call home DOTS server > > is the same whether or not the call home DOTS server is integrated > > with the CPE/NAT (if true)? > > Med: This is not that true. The presence of a NAT at the attack source requires additional processing to identify the source and enforce appropriate actions. Okay. But right now in the text we only mention either figure in "If a translator is enabled on the boundaries of the domain hosting the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in Figures 11 and 12)" -- there's no text specific to just figure 11 or just figure 12. I think we should say something about how they are different, to justify having both figures. > > > > Section 3.3.3 > > > > I think the YANG module might benefit from being moved up a level or > > two in the section hierarchy. > > Med: OK. > > > > > Section 3.3.3.1 > > > > Should we give some indication that 'signal' is the import prefix > > for "ietf-dots-signal-channel" before going into the tree diagram? > > (I do not know what the convention is in this regard.) > > Med: We can add it a mention. > > > > > Section 3.3.3.2 > > > > I suggest reiterating the note from 8782 about needing to check the > > mapping output provided by YANG-to-CBOR in light of the situations > > where differing CBOR/JSON types can arise (e.g., enumerations and > > 64-bit quantities). > > Med: OK > > > > > I guess it's implicit that we reuse the CBOR map keys 8 and 9 for > > lower-port and upper-port in the source-port-range array? > > Med: Yes. > > > > > Section 3.3.3.3 > > > > This module uses the common YANG types defined in [RFC6991] and > > the > > data structure defined in [RFC8791]. > > > > (nit) I think we need another word here, maybe "data structure > > extension" or "data structure statement"? > > Med: OK for "extension" > > > > > list source-icmp-type-range { > > key "lower-type"; > > description > > "ICMP type range. When only lower-type is > > present, it represents a single ICMP type."; > > > > It seems that the interpretation of the source-icmp-type-range list > > is dependent on the IP address family in use. > > Med: Yes. > > Presumably one is > > supposed to infer this from the source-prefix > > Med: It is inferred from the target-prefix (which is mandatory). I'd suggest saying that explicitly to forestall any future questions about it. (I'll skip rehashing the "mandatory" discussion from above.) > (though we don't say > > so), but the source-prefix is optional when these fields are used in > > the base signal channel. It is not entirely clear whether it is > > safe to rely on the target-prefix for address-family determination, > > though (I do not recall any reason why DOTS signal channel doesn't > > work in the presence of a NAPT function). Should the icmp > > attributes only be allowed if the source-prefix is present? > > > > sx:augment-structure "/signal:dots-signal/signal:message-type/" > > + "signal:redirected-signal" { > > description > > "The alternate Call Home DOTS client."; > > > > Is there something we can/should do for the redirected-signal > > augmentation to indicate that the alt-server and alt-server-record > > nodes are removed/useless? > > Med: We do have the following in the bis: > > | +--:(server-to-client-only) > | +-- alt-server string > | +-- alt-server-record* inet:ip-address > > And in the following in this draft: > > +--:(call-home-only) > +-- alt-ch-client? string > +-- alt-ch-client-record* inet:ip-address > +-- ttl? uint32 > > But we can add some text to restate this. Ah, I hadn't looked at that part of the bis yet, sorry. > > > > leaf alt-ch-client { > > type string; > > description > > "FQDN of an alternate Call Home DOTS client."; > > > > Can we discuss a bit what the implications of redirection are for > > (D)TLS mutual authentication of the post-redirection channel? It > > seems that in most cases the alt-ch-client FQDN will be needed to > > perform certificate validation. Perhaps, though, there would be a > > case where a call home server has a set of preconfigured call home > > clients (each with IP > > address(es) and credentials), so a redirection by IP address to a > > different client in that set would still be functional. So, I am > > not sure that we need to make alt-ch-client a mandatory field > > (whether in the YANG or in the prose), but we probably do need to > > have some text earlier in the document covering the implications for > > authenticating the redirected-to peer. I note that in the base > > signal channel, alt-server is mandatory, so we would have some > > precendent for just making als-ch-client mandatory as well. > > > > Med: As you can read in the NEW text above, alt-ch-client is mandatory for the same reasons as in the base spec: certificate validation. I did notice that when I read the NEW text above, yes :) Thanks, Ben From nobody Wed Oct 14 19:25: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 206143A11EB; Wed, 14 Oct 2020 19:25:56 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pGG_IJ4sfAWT; Wed, 14 Oct 2020 19:25:54 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CE1813A11EA; Wed, 14 Oct 2020 19:25:53 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09F2PlhN016747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 22:25:51 -0400 Date: Wed, 14 Oct 2020 19:25:47 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "draft-ietf-dots-signal-call-home.all@ietf.org" , "dots@ietf.org" Message-ID: <20201015022547.GY50845@kduck.mit.edu> References: <7048_1602675845_5F86E485_7048_112_3_787AE7BB302AE849A7480A190F8B93303155FF8F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7048_1602675845_5F86E485_7048_112_3_787AE7BB302AE849A7480A190F8B93303155FF8F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 1 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 02:25:56 -0000 Hi Med, Also inline. On Wed, Oct 14, 2020 at 11:44:05AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Thank you for the detailed review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : mercredi 14 octobre 2020 01:08 > > Ą : draft-ietf-dots-signal-call-home.all@ietf.org > > Cc : dots@ietf.org > > Objet : AD evaluation of draft-ietf-dots-signal-call-home-09 > > > > Hi all, > > > > Nothing super-earth-shattering in here, but there's enough that > > we'll need a revised I-D and some more WG input before I'm ready to > > start the IETF LC. > > > > -Ben > > > > > > YANG lint says: > > > > ietf-dots-call-home@2020-07-07.yang:11: warning: imported module > > "ietf-dots-signal-channel" not used > > > > AFAICT that's a yanglint bug, since we do augment nodes from the > > signal channel. > > [Med] Yes, it is a pyang issue. We have a similar warning for RFC8791 (where sx is defined): Thanks for confirming. > == > $ pyang -f tree --tree-print-structures example-module-aug\@2020-07-07.yang > example-module-aug@2020-07-07.yang:9: warning: imported module "example-module" not used > module: example-module-aug > > augment-structure /exm:address-book/exm:address: > +-- county? string > +-- zipcode? string > == > > > > > I see that this document has a few IPR notices against it; in > > particular, the one at https://datatracker.ietf.org/ipr/3318/ does > > not list any licensing terms ("Unwilling to Commit to the Provisions > > of a), b), or c) Above", where a/b/c are "no license needed for > > implementation"/"RAND with no fee"/"RAND with possible fee"). > > I believe we are working to see if the situation can be clarified > > and the IPR disclosure updated, but I don't know that we need to > > delay any progress until that has occurred. That said, personally, > > I'm not very comfortable about a protocol that potentially is > > encumbered by IPR with unknown license terms. However, I am willing > > to at least advance the document to IETF LC if there is clear WG > > support for doing so, even knowing that use of the protocol would > > potentially be subject to arbitrary terms from the IPR holder. I > > would really like to hear from the WG members on this point. > > [Med] Actually, there is only one IPR disclosure (3328) that is directly made for the document. Some more information below: > * The two IPR disclosures (3318/3337) were made in early stages of the development of the individual submission, especially before WG adoption. > * 3328 is not a new disclosure but an update of 3337 to point to the wg-adopted version. A note was sent to the chairs to inform them about the update. > * I'm not sure that IPR disclosures are transitive. 3318 is not filled directly against draft-ietf-dots-signal-call-home. I believe that the tooling assumes they are transitive (and is right to do so). In essence, "we" don't know which parts of the individual draft the IPR is supposed to apply to without getting legal advice, so if any part of the individual draft's machinery appears in the WG draft we are forced to assume that it is "tainted" by the IPR claim. > > > > I mention it in the section-by-section comments, but we introduce > > the possibility of "wait for administrator approval" in the > > mitigation-request processing pipeline, which could exceed a normal > > CoAP request timeout. I think we need to have some substantive text > > discussion the expected behavior in this case. > > [Med] There is no request timeout because a request that requires an admin validation can be first replied with attack-mitigation-in-progress status. If the request is then rejected by the admin, the status will change to attack-mitigation-withdrawn with conflict-status set to the new code "mitigation-request-rejected" defined in the document. > > Will add more text. Okay. I wasn't sure if (among other things) "attack-mitigation-in-progress" is appropriate for "I'm not actually mitigating anything yet, just waiting for approval". Thanks for adding text. > > > > Section 1.1 > > > > Some of the DDoS attacks like spoofed RST or FIN packets, > > Slowloris, > > and Transport Layer Security (TLS) re-negotiation are difficult > > to > > detect on a home network device without adversely affecting its > > > > (side note) TLS renegotiation as an attack is just keeping a TLS > > connection open and repeatedly re-negotiating to cause the server to > > burn CPU on signing operations? > > [Med] Yes. > > I don't think I've heard of that > > one before. > > [Med] Some DoS tools are supporting this, but I don't have data about recent attacks exploiting it. Unless there is an objection (Tiru?), I would remove the example as we don't need to be exhaustive anyway. I think it's okay to keep the example; it helps get people thinking outside the box. > > > > Section 1.2 > > > > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) > > refers > > to a DOTS signal channel established at the initiative of a DOTS > > server. That is, the DOTS server initiates a secure connection > > to a > > DOTS client, and uses that connection to receive the attack > > traffic > > information (e.g., attack sources) from the DOTS client. More > > details are provided in Section 3. > > > > I think this introductory section needs to be crystal clear for the > > reader about the relationship between the "conventional" signal > > channel DOTS client and the corresponding call home DOTS client for > > a given mitigation process. Some people will expect both things > > with "client" > > in the name to be on the same device, and some people will expect > > the (call home) client to be the device that makes mitigation > > requests, but both cannot be right. The phrase "role reversal" > > might be useful in describing these interpretations, as might a > > forward reference to section 1.4. (Yes, I understand that there is > > no need for either DOTS call home peer to be colocated with any base > > signal channel element, but I think that the default scenario in > > many readers' minds will be the simple role-reversal setup.) > > > > [Med] The NEW text is as follows: > > NEW: > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers > to a DOTS signal channel established at the initiative of a DOTS > server thanks to a role reversal at the (D)TLS layer (Section 3.1). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That is, the DOTS server initiates a secure connection to a DOTS > client, and uses that connection to receive the attack traffic > information (e.g., attack sources) from the DOTS client. > > DOTS agents involved in the DOTS Call Home adhere to the DOTS roles (Maybe "otherwise adhere"?) > as defined in [RFC8612]. For clarity, this document uses "Call Home > DOTS client" (or "Call Home DOTS server") to refer to a DOTS client > (or DOTS server) deployed in a Call Home scenario (Figure 1). DOTS > Call Home agents may (or not) be co-located with DOTS agents that are > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > compliant with [I-D.ietf-dots-rfc8782-bis] (see Section 1.4 for more > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > details). Thanks a bunch; this does seem to meet the "crystal clear" criterion. I am sure that you considered "DOTS Call Home server"/client in the one sentence that uses "DOTS server"/client before the call-home-specific terms are introduced, and don't want to try to nitpick further. > > > Section 1.3 > > > > It's a little unfortunate that we are using the "DMS" acronym in the > > figure here, when we only mention the terminology of RFC 8612 in > > section 2. (That said, I'm willing to leave it as-is for now and > > see if anyone > > complains.) > > [Med] Added this NEW text to the terminology section: > > DDoS Mitigation System (DMS) refers to a system that performs DDoS > mitigation. Sorry, I meant that the figure occurs before the terminology section in the flow of the document. Even expanding "DMS" specifically in the terminology section doesn't change that. (But I don't have a particular proposal to improve things, and am willing to leave it as you have it in the editor's copy.) Thanks, Ben > > > > Section 3.1 > > > > The DOTS signal channel Call Home preserves all but one of the > > DOTS > > client/server roles in the DOTS protocol stack, as compared to > > DOTS > > client-initiated DOTS signal channel protocol > > > > I suppose one could quibble about whether "party allowed to behave > > passively with respect to heartbeats" qualifies as a "client/server > > role" ... I think I'm okay leaving this as-is for now, though. > > > > For example, a home network element (e.g., home router) co- > > located > > with a Call Home DOTS server is the (D)TLS server. However, when > > > > Figure 7 has a box labelled "Call Home DOTS server" and also "(D)TLS > > client" (not server). At first I thought this was trying to make an > > analogy to a (normal) signal channel DOTS server as being the (D)TLS > > server, but that would not be in a home network element. So maybe > > this is just a typo? > > [Med] This is a typo in the text. The figure is correct. Thanks for catching this. > > > > > calling home, the DOTS server initially assumes the role of the > > (D)TLS client, but the network element's role as a DOTS server > > > > We may want to continue using "DOTS Call Home server" in these two > > lines. > > [Med] OK. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Wed Oct 14 23:47: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 92CA43A12F8; Wed, 14 Oct 2020 23:47:02 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48jj3YESqAtU; Wed, 14 Oct 2020 23:46:59 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 8188B3A12F7; Wed, 14 Oct 2020 23:46:59 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id d20so2958435iop.10; Wed, 14 Oct 2020 23:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=77bvwYX4GzV5nvZFhIqlm8vXaMxKwnUSEQJKUING1P8=; b=FpbzrwymX7/JPsBLmPKvudAdne8cEaHHXBpRi3nuyEZyxIzyMCuBGSMEOFGgrAgZMp XlOQYPJNkjCGKTf8/As0NgD4Nvnn8z9nXF9PHgwu8ZOBYkRHmbuFsNXGmmsFMxDfNumF XMVxe/vfo5IS8vgTISz1yBA6sZmsVEYmYWcySbOec1OYgq+bbSbiYyfWEBAdOhhWTwd3 H6OiU4Qf5KsFRWGh0171C6cGE5CRPWg5FPyZG6gmmihYQ49luoNA3RGR5jeK/R/JuFWd Ml8iPbFeKwO9FaDJwEwvYzzUGssuK7R9cBrzY7B82GpQUBigy5pXES/Thkb4hnNzD5Z7 YZaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=77bvwYX4GzV5nvZFhIqlm8vXaMxKwnUSEQJKUING1P8=; b=najQybU4dSKA8oqFMso1rrg9AHgnqhq98Madp4vtpH+GwEqvGwIJmEwKDkrtqN1ez1 5lEL7X5Mx1aeYLloblvKBcrDpi5oAuS4tzuZZD5Gn7Zy6mLumCdBMHhaSVvNM2RR/XYv ueP6l+D+7kqBd9RWRT3dMJEpzGR/1oBAI/ib7bu0QEAQB+34rnkN/nb27+bemGKTE9TH rnxFCQ4vOQiFGGce2DVuV/P+GXvs+Y0qsV0AB5ZfBUu6WxvZz7uSNRdSxg62bDsEnbcO +BjOHSyzkz3WLh3LeoFjrDMBNv1b2JOjQVcIK8/kNai6Ae84OUNQHJoc+uj6zPHEDmtC utyw== X-Gm-Message-State: AOAM533eOpwemhofFlafKyrZdRyjHEdEIylHuGphuXwJDznjXOdizGFz bcUG0Jnp4g+q+novUPhOQcGX80ec5/5TowYhq/w= X-Google-Smtp-Source: ABdhPJxT9WPzcKmApzgzbg5nSFaNXJ/JnhpnTjv0f6IIJXS5kHCgyvr3T3zKqorysi1M7vTYFM+YpBC3FJ/BZCboFOI= X-Received: by 2002:a02:94cd:: with SMTP id x71mr2315379jah.124.1602744418607; Wed, 14 Oct 2020 23:46:58 -0700 (PDT) MIME-Version: 1.0 References: <7048_1602675845_5F86E485_7048_112_3_787AE7BB302AE849A7480A190F8B93303155FF8F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <7048_1602675845_5F86E485_7048_112_3_787AE7BB302AE849A7480A190F8B93303155FF8F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: tirumal reddy Date: Thu, 15 Oct 2020 12:16:47 +0530 Message-ID: To: Mohamed Boucadair Cc: Benjamin Kaduk , "draft-ietf-dots-signal-call-home.all@ietf.org" , "dots@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bca77105b1b003af" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 1 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 06:47:03 -0000 --000000000000bca77105b1b003af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 14 Oct 2020 at 17:14, wrote: > Hi Ben, > > Thank you for the detailed review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoy=C3=A9 : mercredi 14 octobre 2020 01:08 > > =C3=80 : draft-ietf-dots-signal-call-home.all@ietf.org > > Cc : dots@ietf.org > > Objet : AD evaluation of draft-ietf-dots-signal-call-home-09 > > > > Hi all, > > > > Nothing super-earth-shattering in here, but there's enough that > > we'll need a revised I-D and some more WG input before I'm ready to > > start the IETF LC. > > > > -Ben > > > > > > YANG lint says: > > > > ietf-dots-call-home@2020-07-07.yang:11: warning: imported module > > "ietf-dots-signal-channel" not used > > > > AFAICT that's a yanglint bug, since we do augment nodes from the > > signal channel. > > [Med] Yes, it is a pyang issue. We have a similar warning for RFC8791 > (where sx is defined): > > =3D=3D > $ pyang -f tree --tree-print-structures example-module-aug\@2020-07-07.ya= ng > example-module-aug@2020-07-07.yang:9: warning: imported module > "example-module" not used > module: example-module-aug > > augment-structure /exm:address-book/exm:address: > +-- county? string > +-- zipcode? string > =3D=3D > > > > > I see that this document has a few IPR notices against it; in > > particular, the one at https://datatracker.ietf.org/ipr/3318/ does > > not list any licensing terms ("Unwilling to Commit to the Provisions > > of a), b), or c) Above", where a/b/c are "no license needed for > > implementation"/"RAND with no fee"/"RAND with possible fee"). > > I believe we are working to see if the situation can be clarified > > and the IPR disclosure updated, but I don't know that we need to > > delay any progress until that has occurred. That said, personally, > > I'm not very comfortable about a protocol that potentially is > > encumbered by IPR with unknown license terms. However, I am willing > > to at least advance the document to IETF LC if there is clear WG > > support for doing so, even knowing that use of the protocol would > > potentially be subject to arbitrary terms from the IPR holder. I > > would really like to hear from the WG members on this point. > > [Med] Actually, there is only one IPR disclosure (3328) that is directly > made for the document. Some more information below: > * The two IPR disclosures (3318/3337) were made in early stages of the > development of the individual submission, especially before WG adoption. > * 3328 is not a new disclosure but an update of 3337 to point to the > wg-adopted version. A note was sent to the chairs to inform them about th= e > update. > * I'm not sure that IPR disclosures are transitive. 3318 is not filled > directly against draft-ietf-dots-signal-call-home. > > > > > I mention it in the section-by-section comments, but we introduce > > the possibility of "wait for administrator approval" in the > > mitigation-request processing pipeline, which could exceed a normal > > CoAP request timeout. I think we need to have some substantive text > > discussion the expected behavior in this case. > > [Med] There is no request timeout because a request that requires an admi= n > validation can be first replied with attack-mitigation-in-progress status= . > If the request is then rejected by the admin, the status will change to > attack-mitigation-withdrawn with conflict-status set to the new code > "mitigation-request-rejected" defined in the document. > > Will add more text. > > > > > Section 1.1 > > > > Some of the DDoS attacks like spoofed RST or FIN packets, > > Slowloris, > > and Transport Layer Security (TLS) re-negotiation are difficult > > to > > detect on a home network device without adversely affecting its > > > > (side note) TLS renegotiation as an attack is just keeping a TLS > > connection open and repeatedly re-negotiating to cause the server to > > burn CPU on signing operations? > > [Med] Yes. > > I don't think I've heard of that > > one before. > > [Med] Some DoS tools are supporting this, but I don't have data about > recent attacks exploiting it. Unless there is an objection (Tiru?), I wou= ld > remove the example as we don't need to be exhaustive anyway. > SSL renegotiation is a popular DDoS attack, see https://blog.radware.com/security/ssl/2020/08/ssl-protective-technology-tur= ned-attack-vector/ -Tiru > > > > Section 1.2 > > > > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) > > refers > > to a DOTS signal channel established at the initiative of a DOTS > > server. That is, the DOTS server initiates a secure connection > > to a > > DOTS client, and uses that connection to receive the attack > > traffic > > information (e.g., attack sources) from the DOTS client. More > > details are provided in Section 3. > > > > I think this introductory section needs to be crystal clear for the > > reader about the relationship between the "conventional" signal > > channel DOTS client and the corresponding call home DOTS client for > > a given mitigation process. Some people will expect both things > > with "client" > > in the name to be on the same device, and some people will expect > > the (call home) client to be the device that makes mitigation > > requests, but both cannot be right. The phrase "role reversal" > > might be useful in describing these interpretations, as might a > > forward reference to section 1.4. (Yes, I understand that there is > > no need for either DOTS call home peer to be colocated with any base > > signal channel element, but I think that the default scenario in > > many readers' minds will be the simple role-reversal setup.) > > > > [Med] The NEW text is as follows: > > NEW: > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers > to a DOTS signal channel established at the initiative of a DOTS > server thanks to a role reversal at the (D)TLS layer (Section 3.1). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That is, the DOTS server initiates a secure connection to a DOTS > client, and uses that connection to receive the attack traffic > information (e.g., attack sources) from the DOTS client. > > DOTS agents involved in the DOTS Call Home adhere to the DOTS roles > as defined in [RFC8612]. For clarity, this document uses "Call Home > DOTS client" (or "Call Home DOTS server") to refer to a DOTS client > (or DOTS server) deployed in a Call Home scenario (Figure 1). DOTS > Call Home agents may (or not) be co-located with DOTS agents that are > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > compliant with [I-D.ietf-dots-rfc8782-bis] (see Section 1.4 for more > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > details). > > > > Section 1.3 > > > > It's a little unfortunate that we are using the "DMS" acronym in the > > figure here, when we only mention the terminology of RFC 8612 in > > section 2. (That said, I'm willing to leave it as-is for now and > > see if anyone > > complains.) > > [Med] Added this NEW text to the terminology section: > > DDoS Mitigation System (DMS) refers to a system that performs DDoS > mitigation. > > > > > Section 3.1 > > > > The DOTS signal channel Call Home preserves all but one of the > > DOTS > > client/server roles in the DOTS protocol stack, as compared to > > DOTS > > client-initiated DOTS signal channel protocol > > > > I suppose one could quibble about whether "party allowed to behave > > passively with respect to heartbeats" qualifies as a "client/server > > role" ... I think I'm okay leaving this as-is for now, though. > > > > For example, a home network element (e.g., home router) co- > > located > > with a Call Home DOTS server is the (D)TLS server. However, when > > > > Figure 7 has a box labelled "Call Home DOTS server" and also "(D)TLS > > client" (not server). At first I thought this was trying to make an > > analogy to a (normal) signal channel DOTS server as being the (D)TLS > > server, but that would not be in a home network element. So maybe > > this is just a typo? > > [Med] This is a typo in the text. The figure is correct. Thanks for > catching this. > > > > > calling home, the DOTS server initially assumes the role of the > > (D)TLS client, but the network element's role as a DOTS server > > > > We may want to continue using "DOTS Call Home server" in these two > > lines. > > [Med] OK. > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > --000000000000bca77105b1b003af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 14 Oct 2020 at 17:14, <mohamed.boucadair@orange.com&g= t; wrote:
Hi Ben,

Thank you for the detailed review.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Benjamin Kaduk [mailto:kaduk@mit.edu]
> Envoy=C3=A9=C2=A0: mercredi 14 octobre 2020 01:08
> =C3=80=C2=A0: draft-ietf-dots-signal-call-home.all@ietf.org
> Cc=C2=A0: dots@ietf= .org
> Objet=C2=A0: AD evaluation of draft-ietf-dots-signal-call-home-09
>
> Hi all,
>
> Nothing super-earth-shattering in here, but there's enough that > we'll need a revised I-D and some more WG input before I'm rea= dy to
> start the IETF LC.
>
> -Ben
>
>
> YANG lint says:
>
> ietf-dots-call-home@2020-07-07.yang:11: warning: imported module
> "ietf-dots-signal-channel" not used
>
> AFAICT that's a yanglint bug, since we do augment nodes from the > signal channel.

[Med] Yes, it is a pyang issue. We have a similar warning for RFC8791 (wher= e sx is defined):

=3D=3D
$ pyang -f tree --tree-print-structures example-module-aug\@2020-07-07.yang=
example-module-aug@2020-07-07.yang:9: warning: imported module "exampl= e-module" not used
module: example-module-aug

=C2=A0 augment-structure /exm:address-book/exm:address:
=C2=A0 =C2=A0 +-- county?=C2=A0 =C2=A0 string
=C2=A0 =C2=A0 +-- zipcode?=C2=A0 =C2=A0string
=3D=3D

>
> I see that this document has a few IPR notices against it; in
> particular, the one at https://datatracker.ietf.org/ipr/3= 318/ does
> not list any licensing terms ("Unwilling to Commit to the Provisi= ons
> of a), b), or c) Above", where a/b/c are "no license needed = for
> implementation"/"RAND with no fee"/"RAND with poss= ible fee").
> I believe we are working to see if the situation can be clarified
> and the IPR disclosure updated, but I don't know that we need to > delay any progress until that has occurred.=C2=A0 That said, personall= y,
> I'm not very comfortable about a protocol that potentially is
> encumbered by IPR with unknown license terms.=C2=A0 However, I am will= ing
> to at least advance the document to IETF LC if there is clear WG
> support for doing so, even knowing that use of the protocol would
> potentially be subject to arbitrary terms from the IPR holder.=C2=A0 I=
> would really like to hear from the WG members on this point.

[Med] Actually, there is only one IPR disclosure (3328) that is directly ma= de for the document. Some more information below:
* The two IPR disclosures (3318/3337) were made in early stages of the deve= lopment of the individual submission, especially before WG adoption.
* 3328 is not a new disclosure but an update of 3337 to point to the wg-ado= pted version. A note was sent to the chairs to inform them about the update= .=C2=A0
* I'm not sure that IPR disclosures are transitive. 3318 is not filled = directly against draft-ietf-dots-signal-call-home.

>
> I mention it in the section-by-section comments, but we introduce
> the possibility of "wait for administrator approval" in the<= br> > mitigation-request processing pipeline, which could exceed a normal > CoAP request timeout.=C2=A0 I think we need to have some substantive t= ext
> discussion the expected behavior in this case.

[Med] There is no request timeout because a request that requires an admin = validation can be first replied with attack-mitigation-in-progress status. = If the request is then rejected by the admin, the status will change to att= ack-mitigation-withdrawn with conflict-status set to the new code "mit= igation-request-rejected" defined in the document.

Will add more text.

>
> Section 1.1
>
>=C2=A0 =C2=A0 Some of the DDoS attacks like spoofed RST or FIN packets,=
> Slowloris,
>=C2=A0 =C2=A0 and Transport Layer Security (TLS) re-negotiation are dif= ficult
> to
>=C2=A0 =C2=A0 detect on a home network device without adversely affecti= ng its
>
> (side note) TLS renegotiation as an attack is just keeping a TLS
> connection open and repeatedly re-negotiating to cause the server to > burn CPU on signing operations?

[Med] Yes.

=C2=A0 I don't think I've heard of that
> one before.

[Med] Some DoS tools are supporting this, but I don't have data about r= ecent attacks exploiting it. Unless there is an objection (Tiru?), I would = remove the example as we don't need to be exhaustive anyway.


-Tiru


>
> Section 1.2
>
>=C2=A0 =C2=A0 'DOTS signal channel Call Home' (or DOTS Call Hom= e, for short)
> refers
>=C2=A0 =C2=A0 to a DOTS signal channel established at the initiative of= a DOTS
>=C2=A0 =C2=A0 server.=C2=A0 That is, the DOTS server initiates a secure= connection
> to a
>=C2=A0 =C2=A0 DOTS client, and uses that connection to receive the atta= ck
> traffic
>=C2=A0 =C2=A0 information (e.g., attack sources) from the DOTS client.= =C2=A0 More
>=C2=A0 =C2=A0 details are provided in Section 3.
>
> I think this introductory section needs to be crystal clear for the > reader about the relationship between the "conventional" sig= nal
> channel DOTS client and the corresponding call home DOTS client for > a given mitigation process.=C2=A0 Some people will expect both things<= br> > with "client"
> in the name to be on the same device, and some people will expect
> the (call home) client to be the device that makes mitigation
> requests, but both cannot be right.=C2=A0 The phrase "role revers= al"
> might be useful in describing these interpretations, as might a
> forward reference to section 1.4.=C2=A0 (Yes, I understand that there = is
> no need for either DOTS call home peer to be colocated with any base > signal channel element, but I think that the default scenario in
> many readers' minds will be the simple role-reversal setup.)
>

[Med] The NEW text is as follows:

NEW:
=C2=A0 =C2=A0'DOTS signal channel Call Home' (or DOTS Call Home, fo= r short) refers
=C2=A0 =C2=A0to a DOTS signal channel established at the initiative of a DO= TS
=C2=A0 =C2=A0server thanks to a role reversal at the (D)TLS layer (Section = 3.1).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^
=C2=A0 =C2=A0That is, the DOTS server initiates a secure connection to a DO= TS
=C2=A0 =C2=A0client, and uses that connection to receive the attack traffic=
=C2=A0 =C2=A0information (e.g., attack sources) from the DOTS client.

=C2=A0 =C2=A0DOTS agents involved in the DOTS Call Home adhere to the DOTS = roles
=C2=A0 =C2=A0as defined in [RFC8612].=C2=A0 For clarity, this document uses= "Call Home
=C2=A0 =C2=A0DOTS client" (or "Call Home DOTS server") to re= fer to a DOTS client
=C2=A0 =C2=A0(or DOTS server) deployed in a Call Home scenario (Figure 1).= =C2=A0 DOTS
=C2=A0 =C2=A0Call Home agents may (or not) be co-located with DOTS agents t= hat are
=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^
=C2=A0 =C2=A0compliant with [I-D.ietf-dots-rfc8782-bis] (see Section 1.4 fo= r more
=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^
=C2=A0 =C2=A0details).


> Section 1.3
>
> It's a little unfortunate that we are using the "DMS" ac= ronym in the
> figure here, when we only mention the terminology of RFC 8612 in
> section 2.=C2=A0 (That said, I'm willing to leave it as-is for now= and
> see if anyone
> complains.)

[Med] Added this NEW text to the terminology section:

=C2=A0 =C2=A0DDoS Mitigation System (DMS) refers to a system that performs = DDoS
=C2=A0 =C2=A0mitigation.

>
> Section 3.1
>
>=C2=A0 =C2=A0 The DOTS signal channel Call Home preserves all but one o= f the
> DOTS
>=C2=A0 =C2=A0 client/server roles in the DOTS protocol stack, as compar= ed to
> DOTS
>=C2=A0 =C2=A0 client-initiated DOTS signal channel protocol
>
> I suppose one could quibble about whether "party allowed to behav= e
> passively with respect to heartbeats" qualifies as a "client= /server
> role" ... I think I'm okay leaving this as-is for now, though= .
>
>=C2=A0 =C2=A0 For example, a home network element (e.g., home router) c= o-
> located
>=C2=A0 =C2=A0 with a Call Home DOTS server is the (D)TLS server.=C2=A0 = However, when
>
> Figure 7 has a box labelled "Call Home DOTS server" and also= "(D)TLS
> client" (not server).=C2=A0 At first I thought this was trying to= make an
> analogy to a (normal) signal channel DOTS server as being the (D)TLS > server, but that would not be in a home network element.=C2=A0 So mayb= e
> this is just a typo?

[Med] This is a typo in the text. The figure is correct. Thanks for catchin= g this.

>
>=C2=A0 =C2=A0 calling home, the DOTS server initially assumes the role = of the
>=C2=A0 =C2=A0 (D)TLS client, but the network element's role as a DO= TS server
>
> We may want to continue using "DOTS Call Home server" in the= se two
> lines.

[Med] OK.


___________________________________________________________________________= ______________________________________________

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

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

--000000000000bca77105b1b003af-- From nobody Thu Oct 15 00:37: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 727583A1340; Thu, 15 Oct 2020 00:37:28 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m566lBuWAJDY; Thu, 15 Oct 2020 00:37:26 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 E14F13A1338; Thu, 15 Oct 2020 00:37:20 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id w17so3003401ilg.8; Thu, 15 Oct 2020 00:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qaq60cppeF+uxHTsdAk28fVL/yKZ0EvLp2w9D+yTNw8=; b=IlMeL5XSV1EzWSQR2hkM19BdXf8/wPRIXEIWp1iJa3jIyCzPPWlXHDarVgqS5N7+h1 wYQfGmxbZi+zzZAqlo956d0n8X7ruV3lwgGlYHZCYua6JxIyaKEVY3SgvmkGcazSsnic fTH6ZzhvEA9ti1b4a3G3FzIuXkI8sZ2nYZZq9/bVoC4zqE93cYB9Im3eYhwybMMauobI jMR0CJHQ6PrtLyBl4ZIafc0iz++pVZsPsCIsJgnDdLFNLZ6wqjOSZZyPE4skBF/Kt8it g9b5rD6/oKsp/yW66rOSb9CVtRwRFvtnrBiUupk3FQxfsYRkpCITOjlD8P8QTrujSTvy 61TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qaq60cppeF+uxHTsdAk28fVL/yKZ0EvLp2w9D+yTNw8=; b=hisn5s6XjU6yLUaAE6y4ZVp8c2d6ymIQ+VFAa9LqkPd+blpqf7uaLNXjoI63okuW/J VtcndaZeuVzAwSAXjawKuq3hUXXYNZd82mAJqxvbkkXs+zzxh6gqfjGHvgXhNlRHRj4X TEhvkG7ZkqBMUA/GRbtjDPGEi0YVF3jLHceexG4WpEsxp3QjodRclBCWfqs3GXYpJZ0k Jk+qm91vjIlESmPIRiGMWOFbc9a93iQbajPi/FsBNsBMYceavxle9o9w+fvSdKkv6ArQ AcJzBf5lEzCdn5MYgsbkDYtmOWIEq3XEyRW9w77pFlkFgDM4k5z6B/vOUHn2B24S6i0m iXpg== X-Gm-Message-State: AOAM533K/R99WgG9q9FETf1YUHM4qTAm/7Hp2P72NMNtq1T4ln+STpej fNK21C9NGmeNoexoRM9G4CJscYqRd86/cubNTOM= X-Google-Smtp-Source: ABdhPJxgV8re/xf1tCfN7nd14zy9ESIqvk7h0tWMv16ruOMa0e/hwbzgefNn06GxdSxogkuHNTD0JCveKJjeoqWVvN8= X-Received: by 2002:a05:6e02:dea:: with SMTP id m10mr2255844ilj.208.1602747440014; Thu, 15 Oct 2020 00:37:20 -0700 (PDT) MIME-Version: 1.0 References: <7048_1602675845_5F86E485_7048_112_3_787AE7BB302AE849A7480A190F8B93303155FF8F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20201015022547.GY50845@kduck.mit.edu> In-Reply-To: <20201015022547.GY50845@kduck.mit.edu> From: tirumal reddy Date: Thu, 15 Oct 2020 13:07:08 +0530 Message-ID: To: Benjamin Kaduk Cc: Mohamed Boucadair , "draft-ietf-dots-signal-call-home.all@ietf.org" , "dots@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d3a9ef05b1b0b70e" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 1 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 07:37:28 -0000 --000000000000d3a9ef05b1b0b70e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 15 Oct 2020 at 07:55, Benjamin Kaduk wrote: > Hi Med, > > Also inline. > > On Wed, Oct 14, 2020 at 11:44:05AM +0000, mohamed.boucadair@orange.com > wrote: > > Hi Ben, > > > > Thank you for the detailed review. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoy=C3=A9 : mercredi 14 octobre 2020 01:08 > > > =C3=80 : draft-ietf-dots-signal-call-home.all@ietf.org > > > Cc : dots@ietf.org > > > Objet : AD evaluation of draft-ietf-dots-signal-call-home-09 > > > > > > Hi all, > > > > > > Nothing super-earth-shattering in here, but there's enough that > > > we'll need a revised I-D and some more WG input before I'm ready to > > > start the IETF LC. > > > > > > -Ben > > > > > > > > > YANG lint says: > > > > > > ietf-dots-call-home@2020-07-07.yang:11: warning: imported module > > > "ietf-dots-signal-channel" not used > > > > > > AFAICT that's a yanglint bug, since we do augment nodes from the > > > signal channel. > > > > [Med] Yes, it is a pyang issue. We have a similar warning for RFC8791 > (where sx is defined): > > Thanks for confirming. > > > =3D=3D > > $ pyang -f tree --tree-print-structures > example-module-aug\@2020-07-07.yang > > example-module-aug@2020-07-07.yang:9: warning: imported module > "example-module" not used > > module: example-module-aug > > > > augment-structure /exm:address-book/exm:address: > > +-- county? string > > +-- zipcode? string > > =3D=3D > > > > > > > > I see that this document has a few IPR notices against it; in > > > particular, the one at https://datatracker.ietf.org/ipr/3318/ does > > > not list any licensing terms ("Unwilling to Commit to the Provisions > > > of a), b), or c) Above", where a/b/c are "no license needed for > > > implementation"/"RAND with no fee"/"RAND with possible fee"). > > > I believe we are working to see if the situation can be clarified > > > and the IPR disclosure updated, but I don't know that we need to > > > delay any progress until that has occurred. That said, personally, > > > I'm not very comfortable about a protocol that potentially is > > > encumbered by IPR with unknown license terms. However, I am willing > > > to at least advance the document to IETF LC if there is clear WG > > > support for doing so, even knowing that use of the protocol would > > > potentially be subject to arbitrary terms from the IPR holder. I > > > would really like to hear from the WG members on this point. > > > > [Med] Actually, there is only one IPR disclosure (3328) that is directl= y > made for the document. Some more information below: > > * The two IPR disclosures (3318/3337) were made in early stages of the > development of the individual submission, especially before WG adoption. > > * 3328 is not a new disclosure but an update of 3337 to point to the > wg-adopted version. A note was sent to the chairs to inform them about th= e > update. > > * I'm not sure that IPR disclosures are transitive. 3318 is not filled > directly against draft-ietf-dots-signal-call-home. > > I believe that the tooling assumes they are transitive (and is right to d= o > so). In essence, "we" don't know which parts of the individual draft the > IPR is supposed to apply to without getting legal advice, so if any part = of > the individual draft's machinery appears in the WG draft we are forced to > assume that it is "tainted" by the IPR claim. > An update to IPR disclosure (3318) will be published soon. -Tiru > > > > > > > I mention it in the section-by-section comments, but we introduce > > > the possibility of "wait for administrator approval" in the > > > mitigation-request processing pipeline, which could exceed a normal > > > CoAP request timeout. I think we need to have some substantive text > > > discussion the expected behavior in this case. > > > > [Med] There is no request timeout because a request that requires an > admin validation can be first replied with attack-mitigation-in-progress > status. If the request is then rejected by the admin, the status will > change to attack-mitigation-withdrawn with conflict-status set to the new > code "mitigation-request-rejected" defined in the document. > > > > Will add more text. > > Okay. I wasn't sure if (among other things) > "attack-mitigation-in-progress" is appropriate for "I'm not actually > mitigating anything yet, just waiting for approval". Thanks for adding > text. > > > > > > > Section 1.1 > > > > > > Some of the DDoS attacks like spoofed RST or FIN packets, > > > Slowloris, > > > and Transport Layer Security (TLS) re-negotiation are difficult > > > to > > > detect on a home network device without adversely affecting its > > > > > > (side note) TLS renegotiation as an attack is just keeping a TLS > > > connection open and repeatedly re-negotiating to cause the server to > > > burn CPU on signing operations? > > > > [Med] Yes. > > > > I don't think I've heard of that > > > one before. > > > > [Med] Some DoS tools are supporting this, but I don't have data about > recent attacks exploiting it. Unless there is an objection (Tiru?), I wou= ld > remove the example as we don't need to be exhaustive anyway. > > I think it's okay to keep the example; it helps get people thinking outsi= de > the box. > > > > > > > Section 1.2 > > > > > > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) > > > refers > > > to a DOTS signal channel established at the initiative of a DOTS > > > server. That is, the DOTS server initiates a secure connection > > > to a > > > DOTS client, and uses that connection to receive the attack > > > traffic > > > information (e.g., attack sources) from the DOTS client. More > > > details are provided in Section 3. > > > > > > I think this introductory section needs to be crystal clear for the > > > reader about the relationship between the "conventional" signal > > > channel DOTS client and the corresponding call home DOTS client for > > > a given mitigation process. Some people will expect both things > > > with "client" > > > in the name to be on the same device, and some people will expect > > > the (call home) client to be the device that makes mitigation > > > requests, but both cannot be right. The phrase "role reversal" > > > might be useful in describing these interpretations, as might a > > > forward reference to section 1.4. (Yes, I understand that there is > > > no need for either DOTS call home peer to be colocated with any base > > > signal channel element, but I think that the default scenario in > > > many readers' minds will be the simple role-reversal setup.) > > > > > > > [Med] The NEW text is as follows: > > > > NEW: > > 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refer= s > > to a DOTS signal channel established at the initiative of a DOTS > > server thanks to a role reversal at the (D)TLS layer (Section 3.1). > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > That is, the DOTS server initiates a secure connection to a DOTS > > client, and uses that connection to receive the attack traffic > > information (e.g., attack sources) from the DOTS client. > > > > DOTS agents involved in the DOTS Call Home adhere to the DOTS roles > > (Maybe "otherwise adhere"?) > > > as defined in [RFC8612]. For clarity, this document uses "Call Home > > DOTS client" (or "Call Home DOTS server") to refer to a DOTS client > > (or DOTS server) deployed in a Call Home scenario (Figure 1). DOTS > > Call Home agents may (or not) be co-located with DOTS agents that ar= e > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > compliant with [I-D.ietf-dots-rfc8782-bis] (see Section 1.4 for more > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > details). > > Thanks a bunch; this does seem to meet the "crystal clear" criterion. > I am sure that you considered "DOTS Call Home server"/client in the one > sentence that uses "DOTS server"/client before the call-home-specific ter= ms > are introduced, and don't want to try to nitpick further. > > > > > > Section 1.3 > > > > > > It's a little unfortunate that we are using the "DMS" acronym in the > > > figure here, when we only mention the terminology of RFC 8612 in > > > section 2. (That said, I'm willing to leave it as-is for now and > > > see if anyone > > > complains.) > > > > [Med] Added this NEW text to the terminology section: > > > > DDoS Mitigation System (DMS) refers to a system that performs DDoS > > mitigation. > > Sorry, I meant that the figure occurs before the terminology section in t= he > flow of the document. Even expanding "DMS" specifically in the terminolo= gy > section doesn't change that. (But I don't have a particular proposal to > improve things, and am willing to leave it as you have it in the editor's > copy.) > > Thanks, > > Ben > > > > > > > Section 3.1 > > > > > > The DOTS signal channel Call Home preserves all but one of the > > > DOTS > > > client/server roles in the DOTS protocol stack, as compared to > > > DOTS > > > client-initiated DOTS signal channel protocol > > > > > > I suppose one could quibble about whether "party allowed to behave > > > passively with respect to heartbeats" qualifies as a "client/server > > > role" ... I think I'm okay leaving this as-is for now, though. > > > > > > For example, a home network element (e.g., home router) co- > > > located > > > with a Call Home DOTS server is the (D)TLS server. However, when > > > > > > Figure 7 has a box labelled "Call Home DOTS server" and also "(D)TLS > > > client" (not server). At first I thought this was trying to make an > > > analogy to a (normal) signal channel DOTS server as being the (D)TLS > > > server, but that would not be in a home network element. So maybe > > > this is just a typo? > > > > [Med] This is a typo in the text. The figure is correct. Thanks for > catching this. > > > > > > > > calling home, the DOTS server initially assumes the role of the > > > (D)TLS client, but the network element's role as a DOTS server > > > > > > We may want to continue using "DOTS Call Home server" in these two > > > lines. > > > > [Med] OK. > > > > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > > --000000000000d3a9ef05b1b0b70e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 15 Oct 2020 at 07:55, Benjamin Ka= duk <kaduk@mit.edu> wrote:
Hi Med,

Also inline.

On Wed, Oct 14, 2020 at 11:44:05AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben,
>
> Thank you for the detailed review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De=C2=A0: Benjamin Kaduk [mailto:kaduk@mit.edu]
> > Envoy=C3=A9=C2=A0: mercredi 14 octobre 2020 01:08
> > =C3=80=C2=A0: draft-ietf-dots-signal-call-home.all@ietf.o= rg
> > Cc=C2=A0: dots= @ietf.org
> > Objet=C2=A0: AD evaluation of draft-ietf-dots-signal-call-home-09=
> >
> > Hi all,
> >
> > Nothing super-earth-shattering in here, but there's enough th= at
> > we'll need a revised I-D and some more WG input before I'= m ready to
> > start the IETF LC.
> >
> > -Ben
> >
> >
> > YANG lint says:
> >
> > ietf-dots-call-home@2020-07-07.yang:11: warning: imported module<= br> > > "ietf-dots-signal-channel" not used
> >
> > AFAICT that's a yanglint bug, since we do augment nodes from = the
> > signal channel.
>
> [Med] Yes, it is a pyang issue. We have a similar warning for RFC8791 = (where sx is defined):

Thanks for confirming.

> =3D=3D
> $ pyang -f tree --tree-print-structures example-module-aug\@2020-07-07= .yang
> example-module-aug@2020-07-07.yang:9: warning: imported module "e= xample-module" not used
> module: example-module-aug
>
>=C2=A0 =C2=A0augment-structure /exm:address-book/exm:address:
>=C2=A0 =C2=A0 =C2=A0+-- county?=C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0+-- zipcode?=C2=A0 =C2=A0string
> =3D=3D
>
> >
> > I see that this document has a few IPR notices against it; in
> > particular, the one at https://datatracker.ietf.org/= ipr/3318/ does
> > not list any licensing terms ("Unwilling to Commit to the Pr= ovisions
> > of a), b), or c) Above", where a/b/c are "no license ne= eded for
> > implementation"/"RAND with no fee"/"RAND with= possible fee").
> > I believe we are working to see if the situation can be clarified=
> > and the IPR disclosure updated, but I don't know that we need= to
> > delay any progress until that has occurred.=C2=A0 That said, pers= onally,
> > I'm not very comfortable about a protocol that potentially is=
> > encumbered by IPR with unknown license terms.=C2=A0 However, I am= willing
> > to at least advance the document to IETF LC if there is clear WG<= br> > > support for doing so, even knowing that use of the protocol would=
> > potentially be subject to arbitrary terms from the IPR holder.=C2= =A0 I
> > would really like to hear from the WG members on this point.
>
> [Med] Actually, there is only one IPR disclosure (3328) that is direct= ly made for the document. Some more information below:
> * The two IPR disclosures (3318/3337) were made in early stages of the= development of the individual submission, especially before WG adoption. > * 3328 is not a new disclosure but an update of 3337 to point to the w= g-adopted version. A note was sent to the chairs to inform them about the u= pdate.=C2=A0
> * I'm not sure that IPR disclosures are transitive. 3318 is not fi= lled directly against draft-ietf-dots-signal-call-home.

I believe that the tooling assumes they are transitive (and is right to do<= br> so).=C2=A0 In essence, "we" don't know which parts of the ind= ividual draft the
IPR is supposed to apply to without getting legal advice, so if any part of=
the individual draft's machinery appears in the WG draft we are forced = to
assume that it is "tainted" by the IPR claim.

An update to=20 IPR disclosure (3318) will be published soon.

-Tir= u
=C2=A0

> >
> > I mention it in the section-by-section comments, but we introduce=
> > the possibility of "wait for administrator approval" in= the
> > mitigation-request processing pipeline, which could exceed a norm= al
> > CoAP request timeout.=C2=A0 I think we need to have some substant= ive text
> > discussion the expected behavior in this case.
>
> [Med] There is no request timeout because a request that requires an a= dmin validation can be first replied with attack-mitigation-in-progress sta= tus. If the request is then rejected by the admin, the status will change t= o attack-mitigation-withdrawn with conflict-status set to the new code &quo= t;mitigation-request-rejected" defined in the document.
>
> Will add more text.

Okay.=C2=A0 I wasn't sure if (among other things)
"attack-mitigation-in-progress" is appropriate for "I'm = not actually
mitigating anything yet, just waiting for approval".=C2=A0 Thanks for = adding
text.

> >
> > Section 1.1
> >
> >=C2=A0 =C2=A0 Some of the DDoS attacks like spoofed RST or FIN pac= kets,
> > Slowloris,
> >=C2=A0 =C2=A0 and Transport Layer Security (TLS) re-negotiation ar= e difficult
> > to
> >=C2=A0 =C2=A0 detect on a home network device without adversely af= fecting its
> >
> > (side note) TLS renegotiation as an attack is just keeping a TLS<= br> > > connection open and repeatedly re-negotiating to cause the server= to
> > burn CPU on signing operations?
>
> [Med] Yes.
>
>=C2=A0 =C2=A0I don't think I've heard of that
> > one before.
>
> [Med] Some DoS tools are supporting this, but I don't have data ab= out recent attacks exploiting it. Unless there is an objection (Tiru?), I w= ould remove the example as we don't need to be exhaustive anyway.

I think it's okay to keep the example; it helps get people thinking out= side
the box.

> >
> > Section 1.2
> >
> >=C2=A0 =C2=A0 'DOTS signal channel Call Home' (or DOTS Cal= l Home, for short)
> > refers
> >=C2=A0 =C2=A0 to a DOTS signal channel established at the initiati= ve of a DOTS
> >=C2=A0 =C2=A0 server.=C2=A0 That is, the DOTS server initiates a s= ecure connection
> > to a
> >=C2=A0 =C2=A0 DOTS client, and uses that connection to receive the= attack
> > traffic
> >=C2=A0 =C2=A0 information (e.g., attack sources) from the DOTS cli= ent.=C2=A0 More
> >=C2=A0 =C2=A0 details are provided in Section 3.
> >
> > I think this introductory section needs to be crystal clear for t= he
> > reader about the relationship between the "conventional"= ; signal
> > channel DOTS client and the corresponding call home DOTS client f= or
> > a given mitigation process.=C2=A0 Some people will expect both th= ings
> > with "client"
> > in the name to be on the same device, and some people will expect=
> > the (call home) client to be the device that makes mitigation
> > requests, but both cannot be right.=C2=A0 The phrase "role r= eversal"
> > might be useful in describing these interpretations, as might a > > forward reference to section 1.4.=C2=A0 (Yes, I understand that t= here is
> > no need for either DOTS call home peer to be colocated with any b= ase
> > signal channel element, but I think that the default scenario in<= br> > > many readers' minds will be the simple role-reversal setup.)<= br> > >
>
> [Med] The NEW text is as follows:
>
> NEW:
>=C2=A0 =C2=A0 'DOTS signal channel Call Home' (or DOTS Call Hom= e, for short) refers
>=C2=A0 =C2=A0 to a DOTS signal channel established at the initiative of= a DOTS
>=C2=A0 =C2=A0 server thanks to a role reversal at the (D)TLS layer (Sec= tion 3.1).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=C2=A0 =C2=A0 That is, the DOTS server initiates a secure connection to= a DOTS
>=C2=A0 =C2=A0 client, and uses that connection to receive the attack tr= affic
>=C2=A0 =C2=A0 information (e.g., attack sources) from the DOTS client.<= br> >
>=C2=A0 =C2=A0 DOTS agents involved in the DOTS Call Home adhere to the = DOTS roles

(Maybe "otherwise adhere"?)

>=C2=A0 =C2=A0 as defined in [RFC8612].=C2=A0 For clarity, this document= uses "Call Home
>=C2=A0 =C2=A0 DOTS client" (or "Call Home DOTS server") = to refer to a DOTS client
>=C2=A0 =C2=A0 (or DOTS server) deployed in a Call Home scenario (Figure= 1).=C2=A0 DOTS
>=C2=A0 =C2=A0 Call Home agents may (or not) be co-located with DOTS age= nts that are
>=C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^
>=C2=A0 =C2=A0 compliant with [I-D.ietf-dots-rfc8782-bis] (see Section 1= .4 for more
>=C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^
>=C2=A0 =C2=A0 details).

Thanks a bunch; this does seem to meet the "crystal clear" criter= ion.
I am sure that you considered "DOTS Call Home server"/client in t= he one
sentence that uses "DOTS server"/client before the call-home-spec= ific terms
are introduced, and don't want to try to nitpick further.

>
> > Section 1.3
> >
> > It's a little unfortunate that we are using the "DMS&quo= t; acronym in the
> > figure here, when we only mention the terminology of RFC 8612 in<= br> > > section 2.=C2=A0 (That said, I'm willing to leave it as-is fo= r now and
> > see if anyone
> > complains.)
>
> [Med] Added this NEW text to the terminology section:
>
>=C2=A0 =C2=A0 DDoS Mitigation System (DMS) refers to a system that perf= orms DDoS
>=C2=A0 =C2=A0 mitigation.

Sorry, I meant that the figure occurs before the terminology section in the=
flow of the document.=C2=A0 Even expanding "DMS" specifically in = the terminology
section doesn't change that.=C2=A0 (But I don't have a particular p= roposal to
improve things, and am willing to leave it as you have it in the editor'= ;s
copy.)

Thanks,

Ben

> >
> > Section 3.1
> >
> >=C2=A0 =C2=A0 The DOTS signal channel Call Home preserves all but = one of the
> > DOTS
> >=C2=A0 =C2=A0 client/server roles in the DOTS protocol stack, as c= ompared to
> > DOTS
> >=C2=A0 =C2=A0 client-initiated DOTS signal channel protocol
> >
> > I suppose one could quibble about whether "party allowed to = behave
> > passively with respect to heartbeats" qualifies as a "c= lient/server
> > role" ... I think I'm okay leaving this as-is for now, t= hough.
> >
> >=C2=A0 =C2=A0 For example, a home network element (e.g., home rout= er) co-
> > located
> >=C2=A0 =C2=A0 with a Call Home DOTS server is the (D)TLS server.= =C2=A0 However, when
> >
> > Figure 7 has a box labelled "Call Home DOTS server" and= also "(D)TLS
> > client" (not server).=C2=A0 At first I thought this was tryi= ng to make an
> > analogy to a (normal) signal channel DOTS server as being the (D)= TLS
> > server, but that would not be in a home network element.=C2=A0 So= maybe
> > this is just a typo?
>
> [Med] This is a typo in the text. The figure is correct. Thanks for ca= tching this.
>
> >
> >=C2=A0 =C2=A0 calling home, the DOTS server initially assumes the = role of the
> >=C2=A0 =C2=A0 (D)TLS client, but the network element's role as= a DOTS server
> >
> > We may want to continue using "DOTS Call Home server" i= n these two
> > lines.
>
> [Med] OK.
>
>
> ______________________________________________________________________= ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les me= ssages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d information that may be protected by law;
> they should not be distributed, used or copied without authorisation.<= br> > If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>
--000000000000d3a9ef05b1b0b70e-- From nobody Thu Oct 15 06:50: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 C3D283A0A4E; Thu, 15 Oct 2020 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5TfeOBgFiIB; Thu, 15 Oct 2020 06:50:19 -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 6C2833A0A8C; Thu, 15 Oct 2020 06:50:19 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4CBrJN61rbz5wtx; Thu, 15 Oct 2020 15:50:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602769812; bh=autATKfGbskeehOtFY8y5QzWcLakkW1FBuoPDOuxbMg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=iPNsg5j+doxiDEMOUSC9i49/n+OCzg9BCagmsOdkj+EBcseGQ2iFj//I9MMyVgy7k cQ9+wykJ0CFOEPC2vCK7EcfOxWX63Vf8wlDCC1veryU+i2l9SuBLqPy56vFmj8ukIr CrbbfZKKBT1ck66WbUGwr3v6bKHT0ETgwYVQ8wraGNnLoVT2/JyvImsBNQV9VCwVno GSt/AvSToLvXPYT6QlVBJ9STRkTuzhj5/47nGNuYksXj3ZqPc7AAUNRnotStEZvTk0 AVbTVT08SqNTqtYALoz0EIsQTdvTY93E0ZCzKpfn2XfWzIfA00fgdftsD9O8HZjpwj 2dbpKxf2Bh7CQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4CBrJN1N0dzCqky; Thu, 15 Oct 2020 15:50:12 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-call-home.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09 Thread-Index: AQHWobXG5s7gYAJKN0uaM4FUihraeqmWYOIAgAJPS1A= Date: Thu, 15 Oct 2020 13:50:11 +0000 Message-ID: <14893_1602769812_5F885394_14893_347_5_787AE7BB302AE849A7480A190F8B933031560DDF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20201013230819.GA50845@kduck.mit.edu> <20201014043142.GG50845@kduck.mit.edu> In-Reply-To: <20201014043142.GG50845@kduck.mit.edu> 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] AD evaluation of draft-ietf-dots-signal-call-home-09 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 13:50:21 -0000 Hi Ben, all,=20 A candidate version that takes into account your review (and other comments= trigged by the review) can be seen at https://github.com/boucadair/dots-ca= ll-home=20 You may use this link to track the changes: https://tinyurl.com/call-home-B= en-Review=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin > Kaduk > Envoy=E9=A0: mercredi 14 octobre 2020 06:32 > =C0=A0: draft-ietf-dots-signal-call-home.all@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call- > home-09 >=20 > Oops, forgot to note that I also put a bunch of (hopefully!) > editorial suggestions up at https://github.com/boucadair/dots-call- > home/pull/1 rather than littering them here. >=20 > -Ben >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Oct 16 01:19: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 EBBED3A0DDA; Fri, 16 Oct 2020 01:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHvY_MTgaUuO; Fri, 16 Oct 2020 01:19: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 BB5443A0DD8; Fri, 16 Oct 2020 01:19:52 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4CCJwl2NTmz5wwr; Fri, 16 Oct 2020 10:19:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602836391; bh=RphOd5RP1B7yMmxt4ahlk17cDJzexO60tBPFUeOtapU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=SvIsbRn6lpMF+gGr4d9bhcjh8KUbXgHtE0bTohSRJQ33cnSfgWSxME2tzgFxt3ZX3 SVBatbh94JCZ7bKAkkuturJn0meE/A4ET0c672dtjIfqg+4LBZ8OZi/wwWt8ZVRvh+ bSK7vXDF7/05SUZHhtEPqpB2RXmrgUYKxLe+x9/2ImkfIYRLPCrEmm9Ge2oiy4gstr /h9usvuwgpRx0vEQ4BZpxjrz9Ocb4WJ9sJ3jmQAFcFklCyv0Tkk44e9Csow8GeQWTQ 6B4B+ButhNb2XgeckzKomu/5l4MRkF+krtkRC6OsxxkyGC6bQnkc6pOLStIhvcnL3V RB2DZ3KprSuLA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CCJwl1JmJzCql9; Fri, 16 Oct 2020 10:19:51 +0200 (CEST) From: To: Benjamin Kaduk , "supjps-ietf@jpshallow.com" CC: "draft-ietf-dots-signal-call-home.all@ietf.org" , "dots@ietf.org" Thread-Topic: Address scope RE: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3 Thread-Index: AdajlRxgk1r6PozsQFCcA3RAArLPcA== Date: Fri, 16 Oct 2020 08:19:50 +0000 Message-ID: <32350_1602836391_5F8957A7_32350_116_1_787AE7BB302AE849A7480A190F8B9330315617CA@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Address scope RE: AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 08:19:55 -0000 Hi Jon, Ben,=20 > > A bigger challenge that I see is how the Call Home DOTS client > knows (i.e. > > is configured in a trusted way) which Call Home DOTS server is > > responsible for which set of source addresses that the attacks are > actually coming from. >=20 > True, this seems "easy" if the call home client is the ISP but > pretty hard otherwise. Might be worth mentioning as well... > This is not specific to the call home, but applies for the base spec as wel= l. See for example the discussion in 8811:=20 =3D=3D The exact mechanism for the DOTS servers to validate that the resources are= within the scope of the DOTS client domain is deployment specific. For exa= mple, if the DOTS client domain uses Provider-Aggregatable prefixes for its= resources and leverages the DDoS mitigation service of the Internet Transi= t Provider (ITP); the ITP knows the prefixes assigned to the DOTS client do= main because they are assigned by the ITP itself. However, if the DDoS Miti= gation is offered by a third-party DDoS mitigation service provider; it doe= s not know the resources owned by the DOTS client domain. =3D=3D or 8782: =3D=3D DOTS servers MUST verify that requesting DOTS clients are entitled to trigg= er actions on a given IP prefix. That is, only actions on IP resources that= belong to the DOTS client's domain MUST be authorized by a DOTS server. Th= e exact mechanism for the DOTS servers to validate that the target prefixes= are within the scope of the DOTS client domain is deployment specific. =3D=3D Means to avoid maintaining "stale" information would also help (e.g., a net= work that rehome) or detecting a mismatch between the authorized IP prefix = as seen by a client vs. what is seen by the server. These issues can be sol= ved if we extend to data channel to register the IP prefixes "owned" by a d= omain and update them as soon a change occurs. Of course, the procedure to = validate a prefix is in the scope of the domain claiming so would still be = required, but unlike the signal channel, this will happen during idle time. Cheers, Med ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sun Oct 18 21:47:51 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 4367E3A133D; Sun, 18 Oct 2020 21:47:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: draft-ietf-dots-server-discovery.all@ietf.org, dots@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160308286822.22298.8929719132257223868@ietfa.amsl.com> Reply-To: Peter Yee Date: Sun, 18 Oct 2020 21:47:48 -0700 Archived-At: Subject: [Dots] Genart last call review of draft-ietf-dots-server-discovery-12 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 04:47:48 -0000 Reviewer: Peter Yee Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dots-server-discovery-12 Reviewer: Peter Yee Review Date: 2020-10-18 IETF LC End Date: 2020-10-12 IESG Telechat date: Not scheduled for a telechat Summary: This document specifies several methods by which a DOTS agent may be discovered dynamically. The document has a few nits. It also places what may be an unreasonable burden on the need to obtain authentication credentials during an attack. [Ready with Issues] Major issues: None Minor issues: Page 4, section 1, last paragraph: the assumption that a DOTS agent can obtain an authentication credential in the midst of an attack in order to authenticate to another DOTS agent (server) in order to obtain services seems odd. There are already provisions in this document to allow servers to be specified by IP address in order to reduce the need to hit the DNS for a name resolution. But it's considered reasonable to attempt a more complex protocol in order to obtain a credential that may well be server-specific? I think more discussion should be given here, particularly to possible mitigations. One suggestion might be to perform DOTS service discovery periodically (while not under attack) and obtain the credentials needed to access each discovered service. While the set of services that are discovered during an attack may not exactly match those discovered prior to the attack, the idea is that the need for obtaining credentials during an attack could be obviated for services that have not changed during the intervening period. Further considerations could include rediscovering services and obtaining new credentials as old ones expire. Page 6, section 4, 1st paragraph, last sentence: I'd consider dropping this sentence. It presumes that operators do not know how to segregate their hosts between different configuration regimes (manual/static vs. dynamic). Operators might prefer to maintain different DOTS services for hosts on their networks and to configure them with a mix of methods. This is similar to networks with both fixed IP addresses and DHCP services. Operators are expected to deal with configuration correctly and prevent clashes. Page 7, 1st paragraph after the number list, last sentence: I'd say "suitable" might be more suitable (sorry) than "proper". It's not that a device's DNS configuration may not be proper, but that it can't be modified for DOTS purposes. The device may perform all other DNS lookup functions for its primary purpose without issue and still not be able to use DNS for DOTS discovery purposes. Page 11, section 5.1.3, 4th paragraph, 2nd sentence: neither RFC 8415 (section 10) or the sub-referenced RFC 1035 (section 3.1) gives information on "validating" a domain name. What is meant by the term "validating"? Page 11, section 5.1.3, 6th paragraph: add a discussion of what happens if all addresses end up being discarded. It doesn't have to be terribly involved, but the case should be addressed. Do reference identifiers (as when both OPTIONS_V6_DOT_RI and OPTIONS_V6_DOTS_ADDRESS are present) then need to be treated as names to be resolved? Page 13, section 5.2.3, 4th paragraph, 2nd sentence: same comment as given for 5.1.3/4/2. Page 13, section 5.2.3, 6th paragraph: same comment as given for 5.1.3/6. Nits/editorial comments: Page 3, section 1, 1st paragraph, 3rd sentence: change "appraoch" to "approach". Change "allows" to "helps". Page 5, section 3, 2nd bullet item, 1st sentence: change "to associate" to "associating". Page 5, section 3, 2nd bullet item, 2nd sentence: change "to directly provision" to "directly provisioning". Consider swapping "avoiding" and "therefore". Page 6, 2nd bullet item: change "straightforward" to "Straightforward". Page 6, section 4, 2nd paragraph last sentence: change "samples" to "examples". Change the colon to a period. Page 6, list item 1, first bullet item, 1st paragraph, 1st sentence: delete the comma after "A DOTS client". Page 6, last partial sentence: delete the "'s" (apostrophe s). Page 8, section 5, 3rd paragraph: change "to also supply" to "also supplying". Page 8, section 5, 7th paragraph: change "to terminate" to "terminating". Page 11, section 5.1.3, 3rd paragraph, 1st sentence: insert "the" before "reference identifier". Page 11, section 5.1.3, 3rd paragraph, 2nd sentence: insert "an" before "underlying resolution library". Page 13, section 5.2.3, 3rd paragraph, 1st sentence: insert "the" before "reference identifier". Page 15, Figure 8 title: delete "Sample". Page 18, section 8.1, 2nd paragraph, 4th sentence: change "pe-configured" to "pre-configured". Page 18, section 8.1, 2nd paragraph, 5th sentence: insert "a" before "list". Change "DHCP discovered" to "DHCP-discovered". Page 18, section 8.1, 2nd paragraph, last sentence: change "DHCP discovered" to "DHCP-discovered". From nobody Sun Oct 18 23:42: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 314CD3A1420; Sun, 18 Oct 2020 23:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_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 0OBOsDKDDdR7; Sun, 18 Oct 2020 23:42:28 -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 30DC03A1421; Sun, 18 Oct 2020 23:42:28 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4CF6cy3TxWz5wgt; Mon, 19 Oct 2020 08:42:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603089746; bh=SKiWNgdXoCkdDBLrs/whWhfhfHdC0JvqDSYZZWbAobA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bVaU5zCoS4KfqjkRMBw7sLPE/YWdqB4ZopXUSU8EMO2Hfxi6Lvy/ez3vRHYLDym85 jlxb6JEkNLTkZrbcU9qeeIz1azhIxEuVIF3DF9Ne5sCMa6tCtUv9xLM31jo9G21p2O wjlbhA6SQbQxBjPul1NRyp79Bm5zFfELP/nUUkBCULWOar2GL+Tv7ths8jseAcmIfw IgGREviWnclYwUn4ofwQFANo7xQa5tAVTeAyL/+R2USdEan+QHsoJ9WQdP7Xlxpkrq +psqcnO1VoVPyjb3PGIBLO78+7c6fKOH/NO0hqxZVLe8zltyYak1T0L+wAIbMoyzl0 Y5nSHnR8C3v8g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4CF6cy2jrrz8sYR; Mon, 19 Oct 2020 08:42:26 +0200 (CEST) From: To: Peter Yee , "gen-art@ietf.org" CC: "draft-ietf-dots-server-discovery.all@ietf.org" , "dots@ietf.org" , "last-call@ietf.org" Thread-Topic: Genart last call review of draft-ietf-dots-server-discovery-12 Thread-Index: AQHWpdMA5yjHL8KvyEG0PcdqxinmJameab0Q Date: Mon, 19 Oct 2020 06:42:25 +0000 Message-ID: <14283_1603089746_5F8D3552_14283_333_1_787AE7BB302AE849A7480A190F8B9330315625B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160308286822.22298.8929719132257223868@ietfa.amsl.com> In-Reply-To: <160308286822.22298.8929719132257223868@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Genart last call review of draft-ietf-dots-server-discovery-12 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, 19 Oct 2020 06:42:30 -0000 SGkgUGV0ZXIsIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpBbiB1cGRhdGVkIHZl cnNpb24gd2l0aCBjaGFuZ2VzIHRvIGFkZHJlc3MgeW91IHJldmlldyBjYW4gYmUgc2VlbiBhdDog aHR0cHM6Ly9naXRodWIuY29tL2JvdWNhZGFpci9kcmFmdC1pZXRmLWRvdHMtZGlzY292ZXJ5L2Js b2IvbWFzdGVyL2RyYWZ0LWlldGYtZG90cy1zZXJ2ZXItZGlzY292ZXJ5LTEyLnR4dCANCg0KQSBk aWZmIGlzIGFsc28gYXZhaWxhYmxlIGhlcmU6IGh0dHBzOi8vdGlueXVybC5jb20vZG90cy1kaXNj b3ZlcnktcGV0ZXIgDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogUGV0ZXIgWWVlIHZpYSBEYXRhdHJh Y2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogbHVuZGkgMTkgb2N0 b2JyZSAyMDIwIDA2OjQ4DQo+IMOAwqA6IGdlbi1hcnRAaWV0Zi5vcmcNCj4gQ2PCoDogZHJhZnQt aWV0Zi1kb3RzLXNlcnZlci1kaXNjb3ZlcnkuYWxsQGlldGYub3JnOyBkb3RzQGlldGYub3JnOw0K PiBsYXN0LWNhbGxAaWV0Zi5vcmcNCj4gT2JqZXTCoDogR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcg b2YgZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci1kaXNjb3ZlcnktDQo+IDEyDQo+IA0KPiBSZXZpZXdl cjogUGV0ZXIgWWVlDQo+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggSXNzdWVzDQo+IA0KPiBJ IGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2Vu ZXJhbCBBcmVhDQo+IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkNCj4gdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiAg UGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZQ0KPiBhbnkgb3RoZXIgbGFzdCBj YWxsIGNvbW1lbnRzLg0KPiANCj4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhl IEZBUSBhdA0KPiANCj4gPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFy dGZhcT4uDQo+IA0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci1kaXNjb3Zlcnkt MTINCj4gUmV2aWV3ZXI6IFBldGVyIFllZQ0KPiBSZXZpZXcgRGF0ZTogMjAyMC0xMC0xOA0KPiBJ RVRGIExDIEVuZCBEYXRlOiAyMDIwLTEwLTEyDQo+IElFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNj aGVkdWxlZCBmb3IgYSB0ZWxlY2hhdA0KPiANCj4gU3VtbWFyeTogVGhpcyBkb2N1bWVudCBzcGVj aWZpZXMgc2V2ZXJhbCBtZXRob2RzIGJ5IHdoaWNoIGEgRE9UUw0KPiBhZ2VudCBtYXkgYmUgZGlz Y292ZXJlZCBkeW5hbWljYWxseS4gVGhlIGRvY3VtZW50IGhhcyBhIGZldyBuaXRzLiBJdA0KPiBh bHNvIHBsYWNlcyB3aGF0IG1heSBiZSBhbiB1bnJlYXNvbmFibGUgYnVyZGVuIG9uIHRoZSBuZWVk IHRvIG9idGFpbg0KPiBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBkdXJpbmcgYW4gYXR0YWNr LiBbUmVhZHkgd2l0aCBJc3N1ZXNdDQo+IA0KPiBNYWpvciBpc3N1ZXM6IE5vbmUNCj4gDQo+IE1p bm9yIGlzc3VlczoNCj4gDQo+IFBhZ2UgNCwgc2VjdGlvbiAxLCBsYXN0IHBhcmFncmFwaDogdGhl IGFzc3VtcHRpb24gdGhhdCBhIERPVFMgYWdlbnQNCj4gY2FuIG9idGFpbiBhbiBhdXRoZW50aWNh dGlvbiBjcmVkZW50aWFsIGluIHRoZSBtaWRzdCBvZiBhbiBhdHRhY2sgaW4NCj4gb3JkZXIgdG8g YXV0aGVudGljYXRlIHRvIGFub3RoZXIgRE9UUyBhZ2VudCAoc2VydmVyKSBpbiBvcmRlciB0bw0K PiBvYnRhaW4gc2VydmljZXMgc2VlbXMgb2RkLg0KDQpbTWVkXSBUaGVyZSBpcyBubyBzdWNoIGFz c3VtcHRpb24gaW4gdGhlIGRyYWZ0LiBUaGF0IHRleHQgaXMgYWJvdXQgd2hhdCBpcyByZXF1aXJl ZCB0byBwcmUtcHJvdmlzaW9uZWQgc28gdGhhdCBhIGRpc2NvdmVyZWQgc2VydmVyIGNhbiBiZSB1 c2VkLiBBZGQgInByZS0iIHRvIHRoYXQgdGV4dCB0byBhdm9pZCBjb25mdXNpb24uIA0KDQogVGhl cmUgYXJlIGFscmVhZHkgcHJvdmlzaW9ucyBpbiB0aGlzDQo+IGRvY3VtZW50IHRvIGFsbG93IHNl cnZlcnMgdG8gYmUgc3BlY2lmaWVkIGJ5IElQIGFkZHJlc3MgaW4gb3JkZXIgdG8NCj4gcmVkdWNl IHRoZSBuZWVkIHRvIGhpdCB0aGUgRE5TIGZvciBhIG5hbWUgcmVzb2x1dGlvbi4gQnV0IGl0J3MN Cj4gY29uc2lkZXJlZCByZWFzb25hYmxlIHRvIGF0dGVtcHQgYSBtb3JlIGNvbXBsZXggcHJvdG9j b2wgaW4gb3JkZXIgdG8NCj4gb2J0YWluIGEgY3JlZGVudGlhbCB0aGF0IG1heSB3ZWxsIGJlIHNl cnZlci1zcGVjaWZpYz8NCg0KW01lZF0gVGhlIG1lY2hhbmlzbXMgdXNlZCB0byBwcm92aXNpb24g dGhlIGNyZWRlbnRpYWxzIGFyZSBub3QgdGhlIG9uZXMgdXNlZCB0byBkaXNjb3ZlciB0aGUgcmVh Y2hhYmlsaXR5IGluZm9ybWF0aW9uICh0aGluayBhYm91dCBTSVAgYW5kIHRoZSBsaWtlKS4gV2Ug YXJlIGZvbGxvd2luZyBhIHNpbWlsYXIgbW9kZWwgZm9yIERPVFMgYW5kIGhlbmNlIHRoZSBjdXJy ZW50IHNjb3BlIGZvciBkaXNjb3ZlcnkgaW4gdGhlIGRvY3VtZW50LiAgDQoNCiBJIHRoaW5rIG1v cmUNCj4gZGlzY3Vzc2lvbiBzaG91bGQgYmUgZ2l2ZW4gaGVyZSwgcGFydGljdWxhcmx5IHRvIHBv c3NpYmxlDQo+IG1pdGlnYXRpb25zLiBPbmUgc3VnZ2VzdGlvbiBtaWdodCBiZSB0byBwZXJmb3Jt IERPVFMgc2VydmljZQ0KPiBkaXNjb3ZlcnkgcGVyaW9kaWNhbGx5ICh3aGlsZSBub3QgdW5kZXIN Cj4gYXR0YWNrKQ0KDQpbTWVkXSBBcyBpbmRpY2F0ZWQgaW4gU2VjdGlvbiA0LCB0aGUgZGlzY292 ZXJ5IHdpbGwgYmUgZXhlY3V0ZWQgd2hlbiAiYXR0YWNoKGluZykgdG8gYSBuZXcgbmV0d29yayIg KGNvdmVycyB0aGUgYm9vdHN0cmFwcGluZyBjYXNlKSBhbmQgdGhlbiByZWl0ZXJhdGVkIHVwb24g ZXhwaXJ5IG9mIGEgdmFsaWRpdHkgdGltZXIuIE90aGVyIHRyaWdnZXJzIHRvIHJlaXRlcmF0ZSB0 aGUgcHJvY2VkdXJlIGlzDQoNCiBhbmQgb2J0YWluIHRoZSBjcmVkZW50aWFscyBuZWVkZWQgdG8g YWNjZXNzIGVhY2ggZGlzY292ZXJlZA0KPiBzZXJ2aWNlLg0KPiBXaGlsZSB0aGUgc2V0IG9mIHNl cnZpY2VzIHRoYXQgYXJlIGRpc2NvdmVyZWQgZHVyaW5nIGFuIGF0dGFjayBtYXkNCj4gbm90IGV4 YWN0bHkgbWF0Y2ggdGhvc2UgZGlzY292ZXJlZCBwcmlvciB0byB0aGUgYXR0YWNrLCB0aGUgaWRl YSBpcw0KPiB0aGF0IHRoZSBuZWVkIGZvciBvYnRhaW5pbmcgY3JlZGVudGlhbHMgZHVyaW5nIGFu IGF0dGFjayBjb3VsZCBiZQ0KPiBvYnZpYXRlZCBmb3Igc2VydmljZXMgdGhhdCBoYXZlIG5vdCBj aGFuZ2VkIGR1cmluZyB0aGUgaW50ZXJ2ZW5pbmcNCj4gcGVyaW9kLiBGdXJ0aGVyIGNvbnNpZGVy YXRpb25zIGNvdWxkIGluY2x1ZGUgcmVkaXNjb3ZlcmluZyBzZXJ2aWNlcw0KPiBhbmQgb2J0YWlu aW5nIG5ldyBjcmVkZW50aWFscyBhcyBvbGQgb25lcyBleHBpcmUuDQoNCltNZWRdIEFzIGNhbGxl ZCBpbiBTZWN0aW9uIDQsIHJlZGlzY292ZXJ5IHdpbGwgYmUgZG9lc24ndCB1cG9uIGNyZWRlbnRp YWxzIGV4cGlyeS4gDQoNCj4gDQo+IFBhZ2UgNiwgc2VjdGlvbiA0LCAxc3QgcGFyYWdyYXBoLCBs YXN0IHNlbnRlbmNlOiBJJ2QgY29uc2lkZXINCj4gZHJvcHBpbmcgdGhpcyBzZW50ZW5jZS4gSXQg cHJlc3VtZXMgdGhhdCBvcGVyYXRvcnMgZG8gbm90IGtub3cgaG93DQo+IHRvIHNlZ3JlZ2F0ZSB0 aGVpciBob3N0cyBiZXR3ZWVuIGRpZmZlcmVudCBjb25maWd1cmF0aW9uIHJlZ2ltZXMNCj4gKG1h bnVhbC9zdGF0aWMgdnMuIGR5bmFtaWMpLiBPcGVyYXRvcnMgbWlnaHQgcHJlZmVyIHRvIG1haW50 YWluDQo+IGRpZmZlcmVudCBET1RTIHNlcnZpY2VzIGZvciBob3N0cyBvbiB0aGVpciBuZXR3b3Jr cyBhbmQgdG8gY29uZmlndXJlDQo+IHRoZW0gd2l0aCBhIG1peCBvZiBtZXRob2RzLg0KDQpbTWVk XSBUaGlzIGlzIGV4YWN0bHkgd2hhdCB0aGlzIHRleHQgaXMgYWJvdXQuIEFueXdheSwgcmV3b3Jk ZWQgdGhlIHRleHQuICANCg0KIFRoaXMgaXMgc2ltaWxhciB0byBuZXR3b3JrcyB3aXRoIGJvdGgN Cj4gZml4ZWQgSVAgYWRkcmVzc2VzIGFuZCBESENQIHNlcnZpY2VzLiBPcGVyYXRvcnMgYXJlIGV4 cGVjdGVkIHRvIGRlYWwNCj4gd2l0aCBjb25maWd1cmF0aW9uIGNvcnJlY3RseSBhbmQgcHJldmVu dCBjbGFzaGVzLg0KPiANCj4gUGFnZSA3LCAxc3QgcGFyYWdyYXBoIGFmdGVyIHRoZSBudW1iZXIg bGlzdCwgbGFzdCBzZW50ZW5jZTogSSdkIHNheQ0KPiAic3VpdGFibGUiDQo+IG1pZ2h0IGJlIG1v cmUgc3VpdGFibGUgKHNvcnJ5KSB0aGFuICJwcm9wZXIiLiBJdCdzIG5vdCB0aGF0IGENCj4gZGV2 aWNlJ3MgRE5TIGNvbmZpZ3VyYXRpb24gbWF5IG5vdCBiZSBwcm9wZXIsIGJ1dCB0aGF0IGl0IGNh bid0IGJlDQo+IG1vZGlmaWVkIGZvciBET1RTIHB1cnBvc2VzLiBUaGUgZGV2aWNlIG1heSBwZXJm b3JtIGFsbCBvdGhlciBETlMNCj4gbG9va3VwIGZ1bmN0aW9ucyBmb3IgaXRzIHByaW1hcnkgcHVy cG9zZSB3aXRob3V0IGlzc3VlIGFuZCBzdGlsbCBub3QNCj4gYmUgYWJsZSB0byB1c2UgRE5TIGZv ciBET1RTIGRpc2NvdmVyeSBwdXJwb3Nlcy4NCg0KW01lZF0gT0suDQoNCj4gDQo+IFBhZ2UgMTEs IHNlY3Rpb24gNS4xLjMsIDR0aCBwYXJhZ3JhcGgsIDJuZCBzZW50ZW5jZTogbmVpdGhlciBSRkMN Cj4gODQxNSAoc2VjdGlvbg0KPiAxMCkgb3IgdGhlIHN1Yi1yZWZlcmVuY2VkIFJGQyAxMDM1IChz ZWN0aW9uIDMuMSkgZ2l2ZXMgaW5mb3JtYXRpb24NCj4gb24gInZhbGlkYXRpbmciIGEgZG9tYWlu IG5hbWUuIFdoYXQgaXMgbWVhbnQgYnkgdGhlIHRlcm0NCj4gInZhbGlkYXRpbmciPw0KDQpbTWVk XSBUaGUgdmFsaWRhdGlvbiBpcyBhYm91dCBtYWtpbmcgc3VyZSB0aGF0IGhlIGVuY29kaW5nIGZv bGxvd3MgdGhlIG9uZSBpbiAxMDM1IGFuZCB0aGF0IG5vIGNvbXByZXNzaW9uIGZvcm0gaXMgdXNl ZC4NCg0KPiANCj4gUGFnZSAxMSwgc2VjdGlvbiA1LjEuMywgNnRoIHBhcmFncmFwaDogYWRkIGEg ZGlzY3Vzc2lvbiBvZiB3aGF0DQo+IGhhcHBlbnMgaWYgYWxsIGFkZHJlc3NlcyBlbmQgdXAgYmVp bmcgZGlzY2FyZGVkLiBJdCBkb2Vzbid0IGhhdmUgdG8NCj4gYmUgdGVycmlibHkgaW52b2x2ZWQs IGJ1dCB0aGUgY2FzZSBzaG91bGQgYmUgYWRkcmVzc2VkLiBEbyByZWZlcmVuY2UNCj4gaWRlbnRp ZmllcnMgKGFzIHdoZW4gYm90aCBPUFRJT05TX1Y2X0RPVF9SSSBhbmQNCj4gT1BUSU9OU19WNl9E T1RTX0FERFJFU1MgYXJlIHByZXNlbnQpIHRoZW4gbmVlZCB0byBiZSB0cmVhdGVkIGFzDQo+IG5h bWVzIHRvIGJlIHJlc29sdmVkPw0KPiANCg0KW01lZF0gUmVhcnJhbmdlZCB0aGUgdGV4dCBzbyB0 aGF0IG9uZSBhYm91dCB2YWxpZGF0aW5nIGFkZHJlc3NlcyBpcyBkaXNjdXNzZWQgZmlyc3QuIFRo ZSBkaXNjdXNzaW9uIHdpbGwgdGhlbiBiZSB3aGV0aGVyIHZhbGlkIGFkZHJlc3NlcyBhcmUgb2J0 YWluZWQgb3Igbm90LiANCg0KPiBQYWdlIDEzLCBzZWN0aW9uIDUuMi4zLCA0dGggcGFyYWdyYXBo LCAybmQgc2VudGVuY2U6IHNhbWUgY29tbWVudCBhcw0KPiBnaXZlbiBmb3IgNS4xLjMvNC8yLg0K PiANCj4gUGFnZSAxMywgc2VjdGlvbiA1LjIuMywgNnRoIHBhcmFncmFwaDogc2FtZSBjb21tZW50 IGFzIGdpdmVuIGZvcg0KPiA1LjEuMy82Lg0KPiANCg0KW01lZF0gSWRlbSBhcyBhYm92ZS4NCg0K PiBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCg0KW01lZF0gRml4ZWQgYWxsIHRob3NlLiBUaGFu ayB5b3UsIFBldGVyLiANCg0KPiANCj4gUGFnZSAzLCBzZWN0aW9uIDEsIDFzdCBwYXJhZ3JhcGgs IDNyZCBzZW50ZW5jZTogY2hhbmdlICJhcHByYW9jaCIgdG8NCj4gImFwcHJvYWNoIi4gQ2hhbmdl ICJhbGxvd3MiIHRvICJoZWxwcyIuDQo+IA0KPiBQYWdlIDUsIHNlY3Rpb24gMywgMm5kIGJ1bGxl dCBpdGVtLCAxc3Qgc2VudGVuY2U6IGNoYW5nZSAidG8NCj4gYXNzb2NpYXRlIiB0byAiYXNzb2Np YXRpbmciLg0KPiANCj4gUGFnZSA1LCBzZWN0aW9uIDMsIDJuZCBidWxsZXQgaXRlbSwgMm5kIHNl bnRlbmNlOiBjaGFuZ2UgInRvDQo+IGRpcmVjdGx5IHByb3Zpc2lvbiIgdG8gImRpcmVjdGx5IHBy b3Zpc2lvbmluZyIuIENvbnNpZGVyIHN3YXBwaW5nDQo+ICJhdm9pZGluZyIgYW5kICJ0aGVyZWZv cmUiLg0KPiANCj4gUGFnZSA2LCAybmQgYnVsbGV0IGl0ZW06IGNoYW5nZSAic3RyYWlnaHRmb3J3 YXJkIiB0bw0KPiAiU3RyYWlnaHRmb3J3YXJkIi4NCj4gDQo+IFBhZ2UgNiwgc2VjdGlvbiA0LCAy bmQgcGFyYWdyYXBoIGxhc3Qgc2VudGVuY2U6IGNoYW5nZSAic2FtcGxlcyIgdG8NCj4gImV4YW1w bGVzIi4NCj4gQ2hhbmdlIHRoZSBjb2xvbiB0byBhIHBlcmlvZC4NCj4gDQo+IFBhZ2UgNiwgbGlz dCBpdGVtIDEsIGZpcnN0IGJ1bGxldCBpdGVtLCAxc3QgcGFyYWdyYXBoLCAxc3Qgc2VudGVuY2U6 DQo+IGRlbGV0ZSB0aGUgY29tbWEgYWZ0ZXIgIkEgRE9UUyBjbGllbnQiLg0KPiANCj4gUGFnZSA2 LCBsYXN0IHBhcnRpYWwgc2VudGVuY2U6IGRlbGV0ZSB0aGUgIidzIiAoYXBvc3Ryb3BoZSBzKS4N Cj4gDQo+IFBhZ2UgOCwgc2VjdGlvbiA1LCAzcmQgcGFyYWdyYXBoOiBjaGFuZ2UgInRvIGFsc28g c3VwcGx5IiB0byAiYWxzbw0KPiBzdXBwbHlpbmciLg0KPiANCj4gUGFnZSA4LCBzZWN0aW9uIDUs IDd0aCBwYXJhZ3JhcGg6IGNoYW5nZSAidG8gdGVybWluYXRlIiB0bw0KPiAidGVybWluYXRpbmci Lg0KPiANCj4gUGFnZSAxMSwgc2VjdGlvbiA1LjEuMywgM3JkIHBhcmFncmFwaCwgMXN0IHNlbnRl bmNlOiBpbnNlcnQgInRoZSINCj4gYmVmb3JlICJyZWZlcmVuY2UgaWRlbnRpZmllciIuDQo+IA0K PiBQYWdlIDExLCBzZWN0aW9uIDUuMS4zLCAzcmQgcGFyYWdyYXBoLCAybmQgc2VudGVuY2U6IGlu c2VydCAiYW4iDQo+IGJlZm9yZSAidW5kZXJseWluZyByZXNvbHV0aW9uIGxpYnJhcnkiLg0KPiAN Cj4gUGFnZSAxMywgc2VjdGlvbiA1LjIuMywgM3JkIHBhcmFncmFwaCwgMXN0IHNlbnRlbmNlOiBp bnNlcnQgInRoZSINCj4gYmVmb3JlICJyZWZlcmVuY2UgaWRlbnRpZmllciIuDQo+IA0KPiBQYWdl IDE1LCBGaWd1cmUgOCB0aXRsZTogZGVsZXRlICJTYW1wbGUiLg0KPiANCj4gUGFnZSAxOCwgc2Vj dGlvbiA4LjEsIDJuZCBwYXJhZ3JhcGgsIDR0aCBzZW50ZW5jZTogY2hhbmdlICJwZS0NCj4gY29u ZmlndXJlZCIgdG8gInByZS1jb25maWd1cmVkIi4NCj4gDQo+IFBhZ2UgMTgsIHNlY3Rpb24gOC4x LCAybmQgcGFyYWdyYXBoLCA1dGggc2VudGVuY2U6IGluc2VydCAiYSIgYmVmb3JlDQo+ICJsaXN0 Ii4NCj4gQ2hhbmdlICJESENQIGRpc2NvdmVyZWQiIHRvICJESENQLWRpc2NvdmVyZWQiLg0KPiAN Cj4gUGFnZSAxOCwgc2VjdGlvbiA4LjEsIDJuZCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6IGNo YW5nZSAiREhDUA0KPiBkaXNjb3ZlcmVkIiB0byAiREhDUC1kaXNjb3ZlcmVkIi4NCj4gDQo+IA0K DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Oct 21 05:08:02 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 610DF3A0407; Wed, 21 Oct 2020 05:08:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160328208034.27920.3238751082377865278@ietfa.amsl.com> Date: Wed, 21 Oct 2020 05:08:00 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-13.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, 21 Oct 2020 12:08:00 -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) Agent Discovery Authors : Mohamed Boucadair Tirumaleswar Reddy Filename : draft-ietf-dots-server-discovery-13.txt Pages : 25 Date : 2020-10-21 Abstract: This document specifies mechanisms to configure Distributed Denial of Service Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. Knowing the appropriate DOTS server for a given location can be useful to engage mitigation actions even in cases where the DOTS client cannot localize the attack, but only knows that some resources are under attack and that help is needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-server-discovery-13 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-13 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 Oct 21 05:10: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 60F2D3A03FA for ; Wed, 21 Oct 2020 05:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hc9XqzgmFkL for ; Wed, 21 Oct 2020 05:10:24 -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 79CAB3A03F8 for ; Wed, 21 Oct 2020 05:10:24 -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 opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4CGTpQ6qbYz1xql; Wed, 21 Oct 2020 14:10:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603282223; bh=wwjyuGFRRThtoAVwWUkz9++I3m5IgHil5yesAO4z+IM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=khkXVWJg/t8Kr5ZWOe1LN1QHX/YLzgHOQpL8+rr+UxgWSeCsnVLDKjPFPBD1ijlcf 44z90x7b+lAe3EkHr8tR3RHT++oeZgyPkEcpjv9+ZawDSvQ596ISM3Vt3BrRZzndHf JRw/B3LpyCaogRPPXjdHofQAX81MOMterbTfjqI0Ux/TgaAAsimlZuQKqHJ3psPOkt Pkz4MoEZpnXEjIF9CS3EYVw8ujKwdNJXUgfTuh/rKzxsuwGzQOtlFof8skkvDtHgte 4XgcdR4zOJdGD+w90kXJEdTmd7mJl+xcmIvKNRVbcDAJ54wtvEbNbkiGDsg9lVsZ5Y YTbBT+E0OFfaw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4CGTpQ6B3czDq8Z; Wed, 21 Oct 2020 14:10:22 +0200 (CEST) From: To: "dots@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-server-discovery-13.txt Thread-Index: AQHWp6LYepdI7IDB6EWi8qccBP80a6mh9qrg Date: Wed, 21 Oct 2020 12:10:21 +0000 Message-ID: <6417_1603282222_5F90252E_6417_85_1_787AE7BB302AE849A7480A190F8B93303156447B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160328208034.27920.3238751082377865278@ietfa.amsl.com> In-Reply-To: <160328208034.27920.3238751082377865278@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-server-discovery-13.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 12:10:26 -0000 Hi Ben, all,=20 This version is to address the genart review.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 21 octobre 2020 14:08 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-server-discovery-13.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) Agent Discovery > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Filename : draft-ietf-dots-server-discovery-13.txt > Pages : 25 > Date : 2020-10-21 >=20 > Abstract: > This document specifies mechanisms to configure Distributed > Denial of > Service Open Threat Signaling (DOTS) clients with their DOTS > servers. > The discovery procedure also covers the DOTS Signal Channel Call > Home. Knowing the appropriate DOTS server for a given location > can > be useful to engage mitigation actions even in cases where the > DOTS > client cannot localize the attack, but only knows that some > resources > are under attack and that help is needed. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-server-discovery-13 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-server- > discovery-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-server-discovery- > 13 >=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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 21 07:24: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 819433A10D9 for ; Wed, 21 Oct 2020 07:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI31aZdPozeB for ; Wed, 21 Oct 2020 07:24:21 -0700 (PDT) Received: from mail-yb1-xb44.google.com (mail-yb1-xb44.google.com [IPv6:2607:f8b0:4864:20::b44]) (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 81A753A0B87 for ; Wed, 21 Oct 2020 07:23:44 -0700 (PDT) Received: by mail-yb1-xb44.google.com with SMTP id 67so1933741ybt.6 for ; Wed, 21 Oct 2020 07:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vZyc+Z7VtCmyxIy+QGOsbEnlXq2xyJclvDCIKz5YEJg=; b=WuE2NJmDyU5UOAuXNZVMLCVYNHlTaYt5pRoleTuM20r0QKV4/azqyPsrhM1nDIlvMz Z21eJ5DYlYrgQ1/3lgorDn54kW+1K7gpinzCOuRXpVPXWhAxRpggl4qmaqJ18wvkyvoZ rRCKnLFrwclgob+6SQJ3bl3Cxg7HE51ZqC8Ws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vZyc+Z7VtCmyxIy+QGOsbEnlXq2xyJclvDCIKz5YEJg=; b=YZQXzgzWgpyXegl4o76z1up34uxagrlYWJNJ9fp0xtdQM8Ayq8qEHdsfjh7NbPL++U zy2h9AyABPLpdNmcldaW/yQuEJOcgGy8L+pZrDQ5yO43YkSaR2Pd5fna3RFZurMbCUl4 9hu2yEof+4/MnaxMUTURES5z1DQc4EF4U7a1lPNlC9ptTZNLtnm+Xi18CIqh5G5B1nx+ D3m9jrz5QJ7jza74MpXkxtE0wcIYIefAxikJrwk4I+jtKGd/KkahFc3RVPkFiBl58c5K zGig26RVX2ioCi+i9BC7vdL9QRKng1PCu2NFNIzwd0eyXdy3nk/Nz/qJZX3BaLWVRZnz jtdw== X-Gm-Message-State: AOAM531BaFh+3Ni2NGI+lGHp4+KUPK9971r1JtXOdWrfVpIPE7rAH7rn dyuMb6jm98Y+XbQsoCfPvwxA7b+skjYyq9mSOLkWfg== X-Google-Smtp-Source: ABdhPJwusFo/DFffBkNHT0y57uWHyj+2FDBnpBGUVyXEyH0HaMLhjUnM4XGMgQZI/JQUbKOfLCfB55YEZcqUfvm7hJE= X-Received: by 2002:a25:511:: with SMTP id 17mr5772922ybf.296.1603290223528; Wed, 21 Oct 2020 07:23:43 -0700 (PDT) MIME-Version: 1.0 References: <160246137613.594.10649805135544482452@ietfa.amsl.com> <22178_1602577731_5F856543_22178_325_7_787AE7BB302AE849A7480A190F8B93303155F274@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <22178_1602577731_5F856543_22178_325_7_787AE7BB302AE849A7480A190F8B93303155F274@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Kyle Rose Date: Wed, 21 Oct 2020 10:23:33 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: "tsv-art@ietf.org" , "last-call@ietf.org" , "dots@ietf.org" , "draft-ietf-dots-server-discovery.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-server-discovery-11 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, 21 Oct 2020 14:24:23 -0000 On Tue, Oct 13, 2020 at 4:28 AM wrote: > > * Section 4 says: > > > > The discovery method is reiterated by a DOTS agent upon the > > following > > events: > > > > o Expiry of a a validity timer (e.g., DHCP lease, DNS TTL) > > associated with a discovered DOTS agent. > > > > >From my reading, rendezvous information for the DOTS server is > > "pushed" > > >to the > > client via DHCP, so it's not clear the above is actionable. Is it > > simply the case that a client should use the DOTS server assigned in > > the most recent lease? > > > > [Med] The intent is to avoid using "stale" servers. So yes, this is about using the server that was most recently discovered but also about not using a server beyond a validity time associated with the discovered server. I think the wording for this requirement should be normative rather than buried in the description of the discovery mechanism. Adding a statement somewhere that "a DOTS agent MUST NOT initiate or continue communicating with a server whose associated discovery metadata has expired: for instance, once a DNS TTL or DHCP lease has expired, an appropriate DOTS server must be rediscovered using one of the mechanisms in {}." > > Using DHCP, an inherently insecure protocol, to inform DOTS clients > > of the hostname of DOTS server knocks this third leg out, calling > > into question the entire mechanism. > > [Med] We didn't include such discussion as this is a variation of agent impersonation (covered by the pointer to RFC8811) and rogue servers in RFC8415. Also, we have the following: > > This document assumes that security credentials to authenticate DOTS > server(s) are provisioned to a DOTS client using a mechanism such as > (but not limited to) those discussed in [RFC8572] ... > > We can add some text to elaborate on this further. No, I think this is fine as-is. I think I just missed these references to 8572. > > Is the final label zero-length? > > [Med] Yes, as indicated in 5.2.1: > > o Peer DOTS agent name: The domain name of the peer DOTS agent. > This field is formatted as specified in Section 10 of [RFC8415]. > > Other parts of the DHCPv4 protocol > > terminate domain names with a zero-length label. What if a zero- > > length label appears in some s_i other than the final one? > > > > [Med] Names are validated as per the rules in Section 10 of RFC8415: > > If the DHCP client receives OPTION_V4_DOTS_RI only, but > OPTION_V4_DOTS_RI option contains more than one name, as > distinguished by the presence of multiple root labels, the DHCP > client MUST use only the first name. Once the name is validated > (Section 10 of [RFC8415]), the name is passed to a name resolution > library. Got it. It's a roundabout way of saying "ignore everything after the first zero-length label". I'm guessing this is well-understood by the DNS community. > > RFC 6763 says that an empty TXT record MUST be included alongside > > the SRV record where DNS-SD is concerned. Should normative language > > be used here, or should we rely on the normative reference in case > > that guidance changes in the future? > > [Med] I don't think that the use of normative language is needed here. RFC6763 is sufficient by its own. Sounds good. Thanks for the follow-up. My apologies for the delay in responding. Kyle From nobody Wed Oct 21 08:00:19 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012FC3A12B2; Wed, 21 Oct 2020 08:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQE9xEBKcj0C; Wed, 21 Oct 2020 08:00:12 -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 2C2BF3A1287; Wed, 21 Oct 2020 08:00:12 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4CGYZL3ZWRzBshB; Wed, 21 Oct 2020 17:00:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603292410; bh=2PJAUyE9qUZW0RK9Tu8JPUG0G4VPNpR6uauu2s4YHt0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=J+Aq13P5DZdkUEhe0347kgb/ZdPFH7NX0TNeguA1rfa8/VmfFvTgV7oqm24dKncs+ 8iYP4XpcWSVDOlXy2N1aj6vRo76JwaxOtmJy5oR9sfbpPLbsABfOz2LeAlbae/WWGQ 1sji655R2aOWABVPcrphIlgtdXQJ2u570wkgDTFVARsY9h+dg2r2UTJF9ou69vn3cd VePUNdKoQSHEPTB+j22X6vievFiaONG9brx9Ls8Soh+9ekQ8G60yLsyLzcCCByj0vv ARAwjuSl6fsELCC1RR59nheUrnH7mev9LsUcq8jv/PqHA/A+bXDRus3sTWjAVuePBz ri/lwuzQ3v8Ug== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CGYZL20YjzCqlQ; Wed, 21 Oct 2020 17:00:10 +0200 (CEST) From: To: Kyle Rose CC: "tsv-art@ietf.org" , "last-call@ietf.org" , "dots@ietf.org" , "draft-ietf-dots-server-discovery.all@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-dots-server-discovery-11 Thread-Index: AQHWp7XJRgdZ4S16aEekcYyNLJrIR6miH2Iw Date: Wed, 21 Oct 2020 15:00:09 +0000 Message-ID: <25324_1603292410_5F904CFA_25324_477_9_787AE7BB302AE849A7480A190F8B93303156475C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160246137613.594.10649805135544482452@ietfa.amsl.com> <22178_1602577731_5F856543_22178_325_7_787AE7BB302AE849A7480A190F8B93303155F274@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-server-discovery-11 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, 21 Oct 2020 15:00:15 -0000 SGkgS3lsZSwgDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogS3lsZSBSb3NlIFttYWlsdG86a3Jvc2VA a3Jvc2Uub3JnXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDIxIG9jdG9icmUgMjAyMCAxNjoyNA0K PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPg0KPiBDY8KgOiB0c3YtYXJ0QGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmc7IGRv dHNAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpZXRmLWRvdHMtc2VydmVyLWRpc2NvdmVyeS5hbGxAaWV0 Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFRzdmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWll dGYtZG90cy1zZXJ2ZXItDQo+IGRpc2NvdmVyeS0xMQ0KPiANCj4gT24gVHVlLCBPY3QgMTMsIDIw MjAgYXQgNDoyOCBBTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gd3JvdGU6DQo+ ID4gPiAqIFNlY3Rpb24gNCBzYXlzOg0KPiA+ID4NCj4gPiA+ICAgIFRoZSBkaXNjb3ZlcnkgbWV0 aG9kIGlzIHJlaXRlcmF0ZWQgYnkgYSBET1RTIGFnZW50IHVwb24gdGhlDQo+ID4gPiBmb2xsb3dp bmcNCj4gPiA+ICAgIGV2ZW50czoNCj4gPiA+DQo+ID4gPiAgICBvICBFeHBpcnkgb2YgYSBhIHZh bGlkaXR5IHRpbWVyIChlLmcuLCBESENQIGxlYXNlLCBETlMgVFRMKQ0KPiA+ID4gICAgICAgYXNz b2NpYXRlZCB3aXRoIGEgZGlzY292ZXJlZCBET1RTIGFnZW50Lg0KPiA+ID4NCj4gPiA+ID5Gcm9t IG15IHJlYWRpbmcsIHJlbmRlenZvdXMgaW5mb3JtYXRpb24gZm9yIHRoZSBET1RTIHNlcnZlciBp cw0KPiA+ID4gInB1c2hlZCINCj4gPiA+ID50byB0aGUNCj4gPiA+IGNsaWVudCB2aWEgREhDUCwg c28gaXQncyBub3QgY2xlYXIgdGhlIGFib3ZlIGlzIGFjdGlvbmFibGUuIElzDQo+IGl0DQo+ID4g PiBzaW1wbHkgdGhlIGNhc2UgdGhhdCBhIGNsaWVudCBzaG91bGQgdXNlIHRoZSBET1RTIHNlcnZl cg0KPiBhc3NpZ25lZCBpbg0KPiA+ID4gdGhlIG1vc3QgcmVjZW50IGxlYXNlPw0KPiA+ID4NCj4g Pg0KPiA+IFtNZWRdIFRoZSBpbnRlbnQgaXMgdG8gYXZvaWQgdXNpbmcgInN0YWxlIiBzZXJ2ZXJz LiBTbyB5ZXMsIHRoaXMNCj4gaXMgYWJvdXQgdXNpbmcgdGhlIHNlcnZlciB0aGF0IHdhcyBtb3N0 IHJlY2VudGx5IGRpc2NvdmVyZWQgYnV0IGFsc28NCj4gYWJvdXQgbm90IHVzaW5nIGEgc2VydmVy IGJleW9uZCBhIHZhbGlkaXR5IHRpbWUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiBkaXNjb3ZlcmVk IHNlcnZlci4NCj4gDQo+IEkgdGhpbmsgdGhlIHdvcmRpbmcgZm9yIHRoaXMgcmVxdWlyZW1lbnQg c2hvdWxkIGJlIG5vcm1hdGl2ZSByYXRoZXINCj4gdGhhbiBidXJpZWQgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIHRoZSBkaXNjb3ZlcnkgbWVjaGFuaXNtLiBBZGRpbmcgYQ0KPiBzdGF0ZW1lbnQgc29t ZXdoZXJlIHRoYXQgImEgRE9UUyBhZ2VudCBNVVNUIE5PVCBpbml0aWF0ZSBvciBjb250aW51ZQ0K DQpbTWVkXSBUaGUgbm9ybWF0aXZlIGxhbmd1YWdlIGlzIG5vdCB1c2VkIGJlY2F1c2UgbWFuYWdp bmcgc2Vzc2lvbnMgaXMgYmV5b25kIGRpc2NvdmVyeS4gU3VjaCBiZWhhdmlvciB3aWxsIGRlcGVu ZCBvbiB0aGUgRE9UUyBjaGFubmVsIGFuZCB3aGV0aGVyIGEgRE9UUyBhZ2VudCBpcyBpbiBpZGxl IG9yIGF0dGFjayB0aW1lLiBGb3IgZXhhbXBsZSwgaW1tZWRpYXRlbHkgY2xvc2luZyBhIGNvbW11 bmljYXRpb24gd2l0aCBhIHBlZXIgRE9UUyBhZ2VudCB3aGlsZSBhbiBhdHRhY2sgbWl0aWdhdGlv biBpcyBpbiBwcm9ncmVzcyBtYXkgbm90IGJlIGNvbnZlbmllbnQuIFdlIGhhdmUgc3VjaCBleGNl cHRpb25zIGluIFJGQzg3ODIsIGUuZy4sDQoNCiAgICJUaGlzIGZhbGxiYWNrIG1lY2hhbmlzbSBp cyB0cmlnZ2VyZWQgaW1tZWRpYXRlbHkgdXBvbg0KICAgZXhwaXJ5IG9mIHRoZSBUVEwsIGV4Y2Vw dCB3aGVuIGEgRERvUyBhdHRhY2sgaXMgYWN0aXZlLiINCg0KPiBjb21tdW5pY2F0aW5nIHdpdGgg YSBzZXJ2ZXIgd2hvc2UgYXNzb2NpYXRlZCBkaXNjb3ZlcnkgbWV0YWRhdGEgaGFzDQo+IGV4cGly ZWQ6IGZvciBpbnN0YW5jZSwgb25jZSBhIEROUyBUVEwgb3IgREhDUCBsZWFzZSBoYXMgZXhwaXJl ZCwgYW4NCj4gYXBwcm9wcmlhdGUgRE9UUyBzZXJ2ZXIgbXVzdCBiZSByZWRpc2NvdmVyZWQgdXNp bmcgb25lIG9mIHRoZQ0KPiBtZWNoYW5pc21zIGluIHt9LiINCg0KRldJVywgeW91ciByZXZpZXcg d2FzIHRha2VuIGludG8gYWNjb3VudCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWRvdHMtc2VydmVyLWRpc2NvdmVyeS0xMi50eHQuIFNlZSB0aGUgc2Vj dXJpdHkgc2VjdGlvbiwgaW4gcGFydGljdWxhci4gDQoNClRoYW5rIHlvdS4NCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== From nobody Thu Oct 22 01:42: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 9982F3A0FC2; Thu, 22 Oct 2020 01:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgsnaToTxSPZ; Thu, 22 Oct 2020 01:42:13 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F553A0FB8; Thu, 22 Oct 2020 01:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qVGS8bjKqv5T8dq0xaK3qnFQVBCeghSh6+pB/iaMk/4=; b=xBEZdCIBc2Kt/+Kj6O7vWsGcua Mw1Ibx9xf6mIQKYHZGNxt7dYbpAm5Tt+5dojavtp1oLir00feRyCThGcrTaVeNphU31Vf7F56slK7 3KgLRo7HB15p1EC+no/MnicSPV5cFcB2MAvAo84IOntPyMf2puTCXscimYPfqdxo8zqnL97IGzVZK Gs4CJ/1UGBdfbKnhZvCT9c4hM5pRomngKLBwiw1mwggkGnS5+oCi4lq6dcy9wotdMi2UUhrlY3m0i gL3NN3OyPrRb/nVYreJudtQ9QUX7LvHfe77NIiGgE+Y2nTXi+eEy6V46SAKNTMzbrHbdOqOyWG73Z BAOsZX4w==; Received: from [93.188.44.203] (port=63831 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kVWAk-0001oU-Rd; Thu, 22 Oct 2020 04:42:11 -0400 From: "Valery Smyslov" To: Cc: , References: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> In-Reply-To: <14ca01d69bd5$dbf0d0a0$93d271e0$@smyslov.net> Date: Thu, 22 Oct 2020 11:42:08 +0300 Message-ID: <085201d6a84f$3cc53c10$b64fb430$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHaSW9CC59W3Vb/kWpl9RTUAcwqaamcCwCg Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-rfc8782-bis-01 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, 22 Oct 2020 08:42:15 -0000 Hi, the WGLC for draft-ietf-dots-rfc8782-bis-01 is over. We received no objections to publish this document. Regards, Frank & Valery. > Hi, > > this message starts a two-week working group last call for draft-ietf-dots-rfc8782-bis-01, > which will end on Wednesday, October 21. Please, review the draft carefully and > send your comments to the mailing list. > > Regards, > Frank & Valery. From nobody Thu Oct 22 06:00:41 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 5A0453A0A90; Thu, 22 Oct 2020 06:00:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160337163929.12987.14131696158893014388@ietfa.amsl.com> Date: Thu, 22 Oct 2020 06:00:39 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-call-home-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 13:00:40 -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) Signal Channel Call Home Authors : Tirumaleswar Reddy Mohamed Boucadair Jon Shallow Filename : draft-ietf-dots-signal-call-home-10.txt Pages : 41 Date : 2020-10-22 Abstract: This document specifies the DOTS signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client, and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- rfc8782-bis) Please update TBD/TBA statements with the assignments made by IANA to DOTS Signal Channel Call Home. Also, please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-10 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call-home-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-10 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 Mon Oct 26 19:06:44 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 726883A11D1; Mon, 26 Oct 2020 19:06:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dots-server-discovery@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , valery@smyslov.net X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160376439800.28769.11555549483055573494@ietfa.amsl.com> Date: Mon, 26 Oct 2020 19:06:38 -0700 Archived-At: Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 02:06:39 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dots-server-discovery-13: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Pulling in some follow-up from the directorate review comments... Section 3 o Resolving a DOTS server domain name offered by an upstream transit provider provisioned to a DOTS client into IP address(es) requires the use of the appropriate DNS resolvers; otherwise, resolving those names will fail. The use of protocols such as DHCP does allow associating provisioned DOTS server domain names with a list of DNS servers to be used for name resolution. Furthermore, DHCP allows directly provisioning IP addresses therefore avoiding the need for extra lookup delays. I wonder if using "providing" rather than "provisioning" for at least the last instance would be more clear. o A resolution mechanism based on straightforward Naming Authority Pointer (S-NAPTR) resource records in the Domain Name System (DNS) (Section 6). "Straightforward" needs to be capitalized here. Section 4 will support a local configuration. More samples are discussed in Section 3: nit: s/:/./ Section 5 The list of the IP addresses returned by DHCP servers is typically used to feed the DOTS server selection procedure including when DOTS agents are provided with primary and backup IP addresses of their peer DOTS agents. An example of DOTS server selection procedure is specified in Section 4.3 of [RFC8782]. The referenced section in 8782 is about the "happy eyeballs", i.e., picking between TCP/UDP and IPv4/IPv6 -- it doesn't really seem intended to cover the case where you have to pick betwen different actual nodes. I'm also not sure how the "primary and backup" is intended to work, here. Is the "provided with" referring to "by DHCP" or some out-of-band configuration? Section 8.1 configured name. If the DOTS agent is instructed to trust subdomains of the names in that list as well, a DOTS agent will also accept a DHCP-discovered name if the left-most label of the discovered name is matching a name in the pre-configured list. If the agent is configured to trust subdomains of the configured list, then in the case where that configuration is relevant for the attack, the left-most label will be the (part of the) subdomain name, which is explicitly not matching the pre-configured list -- the remaining bits are what match. From nobody Tue Oct 27 00:09: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 A3FA83A1603; Tue, 27 Oct 2020 00:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQzvvw1eTp-r; Tue, 27 Oct 2020 00:09:24 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574093A1602; Tue, 27 Oct 2020 00:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iBgKGsQhNLCTYwtRIklB8AiH2YQa7CnsNodZ9BiqREY=; b=PQmFfTf6aOcfNS8CxwnCdWJNYY HOFEo8HEa0TL0NUy2T8tvwqrM1RKUpQ4L0sPSPY5enmFwipnEQh08AEOGKhNzUYRVVRd8xNg+wrZn dz2cWfvQClSECNdW26vMoK9Ush3Ybpu3dyC0oTKGicwfQQeCHN8Q9UGzb8HZ5r+RRu0ScmXa57u/5 p7dLO691sWv6tcdnP8v5QL+wq5tTg2b+v9bZPCS3Fdnh09i9nUilvEbD9tjXfkOdCANn3uzNlQCry 6AhVYNSa3ED27xdg9yaWmKqaA18UnGZIsY4KOz+xyvlAxHIKD3eOXZIN3jy1PCSQLCptpALS5Hb9e W6vDY/1A==; Received: from [93.188.44.203] (port=55171 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kXJ6f-0005s8-3N; Tue, 27 Oct 2020 03:09:21 -0400 From: "Valery Smyslov" To: Cc: , Date: Tue, 27 Oct 2020 10:09:20 +0300 Message-ID: <0bf101d6ac30$19120f70$4b362e50$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdasL4ASXwxVJBhRRl2Q1ycZxouChA== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [Dots] WGLC for draft-ietf-dots-telemetry-13 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, 27 Oct 2020 07:09:26 -0000 Hi, this message starts a two-week working group last call for draft-ietf-dots-telemetry-13, which will end on Wednesday, November 11. Please, review the draft carefully and send your comments to the mailing list. Regards, Frank & Valery. From nobody Tue Oct 27 00:25: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 44E9D3A1618; Tue, 27 Oct 2020 00:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZLVEfircQI2; Tue, 27 Oct 2020 00:25:08 -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 3DEEF3A1608; Tue, 27 Oct 2020 00:25:08 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4CL3BV5lXDz5w1P; Tue, 27 Oct 2020 08:25:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603783506; bh=vhjFFM9Kk8amOY3GEMNenfKn1FGTioLsJW4HK0/0U+U=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bMyMoqDQS05iOek0utUP0q4e0ocy/MUC0QQMooMNkTrOdM3VNzNyE8Bw0njAV3cGi Dc/TNCubK/P+7uq5BfsJX29P1CSRgk546Tws4QdYA03g7D842UGM0BM74hc+VHUpQl yEntdFOVhFARQqMwI2pOIqVclh9zLH6khfEH8c5XAWzZ2iDLisZ38pvuvzWy7foyM6 pCW8ilAU6gi346DfX71pM25cFAJgaUiXw+6odXEZKP9DsMv1OJ1ZkpxZWtFrRY0kfU /Vc3N6pmGO+KWiR27pqvGWjHd2j8qDgTNNCPATGu5nVi3NUQ0zEaoFxvPyYDAxSyRN D/IHpzWh4MgZw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4CL3BV4x7bz8sYL; Tue, 27 Oct 2020 08:25:06 +0100 (CET) From: To: Benjamin Kaduk CC: "draft-ietf-dots-server-discovery@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: (with COMMENT) Thread-Index: AQHWrAXPdruIhyGMcEm9MD0LXQC416mrAGxw Date: Tue, 27 Oct 2020 07:25:06 +0000 Message-ID: <30446_1603783506_5F97CB52_30446_33_1_787AE7BB302AE849A7480A190F8B9330315673E7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160376439800.28769.11555549483055573494@ietfa.amsl.com> In-Reply-To: <160376439800.28769.11555549483055573494@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 07:25:10 -0000 SGkgQmVuLCANCg0KQW4gdXBkYXRlZCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDogaHR0cHM6Ly90 aW55dXJsLmNvbS9kb3RzLWRpc2NvdmVyeS1pZXNnIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoN CkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBC ZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0K PiBFbnZvecOpwqA6IG1hcmRpIDI3IG9jdG9icmUgMjAyMCAwMzowNw0KPiDDgMKgOiBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci1kaXNjb3Zl cnlAaWV0Zi5vcmc7IGRvdHMtDQo+IGNoYWlyc0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgVmFs ZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47DQo+IHZhbGVyeUBzbXlzbG92Lm5ldA0K PiBPYmpldMKgOiBCZW5qYW1pbiBLYWR1aydzIFllcyBvbiBkcmFmdC1pZXRmLWRvdHMtc2VydmVy LWRpc2NvdmVyeS0xMzoNCj4gKHdpdGggQ09NTUVOVCkNCj4gDQo+IEJlbmphbWluIEthZHVrIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRm LWRvdHMtc2VydmVyLWRpc2NvdmVyeS0xMzogWWVzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiBhbGwgZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8NCj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiAN Cj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zZXJ2ZXIt ZGlzY292ZXJ5Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiBDT01NRU5UOg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiANCj4gUHVsbGluZyBpbiBzb21lIGZvbGxvdy11cCBmcm9t IHRoZSBkaXJlY3RvcmF0ZSByZXZpZXcgY29tbWVudHMuLi4NCj4gDQo+IFNlY3Rpb24gMw0KPiAN Cj4gICAgbyAgUmVzb2x2aW5nIGEgRE9UUyBzZXJ2ZXIgZG9tYWluIG5hbWUgb2ZmZXJlZCBieSBh biB1cHN0cmVhbQ0KPiB0cmFuc2l0DQo+ICAgICAgIHByb3ZpZGVyIHByb3Zpc2lvbmVkIHRvIGEg RE9UUyBjbGllbnQgaW50byBJUCBhZGRyZXNzKGVzKQ0KPiByZXF1aXJlcw0KPiAgICAgICB0aGUg dXNlIG9mIHRoZSBhcHByb3ByaWF0ZSBETlMgcmVzb2x2ZXJzOyBvdGhlcndpc2UsIHJlc29sdmlu Zw0KPiAgICAgICB0aG9zZSBuYW1lcyB3aWxsIGZhaWwuICBUaGUgdXNlIG9mIHByb3RvY29scyBz dWNoIGFzIERIQ1AgZG9lcw0KPiAgICAgICBhbGxvdyBhc3NvY2lhdGluZyBwcm92aXNpb25lZCBE T1RTIHNlcnZlciBkb21haW4gbmFtZXMgd2l0aCBhDQo+IGxpc3QNCj4gICAgICAgb2YgRE5TIHNl cnZlcnMgdG8gYmUgdXNlZCBmb3IgbmFtZSByZXNvbHV0aW9uLiAgRnVydGhlcm1vcmUsDQo+IERI Q1ANCj4gICAgICAgYWxsb3dzIGRpcmVjdGx5IHByb3Zpc2lvbmluZyBJUCBhZGRyZXNzZXMgdGhl cmVmb3JlIGF2b2lkaW5nDQo+IHRoZQ0KPiAgICAgICBuZWVkIGZvciBleHRyYSBsb29rdXAgZGVs YXlzLg0KPiANCj4gSSB3b25kZXIgaWYgdXNpbmcgInByb3ZpZGluZyIgcmF0aGVyIHRoYW4gInBy b3Zpc2lvbmluZyIgZm9yIGF0DQo+IGxlYXN0IHRoZSBsYXN0IGluc3RhbmNlIHdvdWxkIGJlIG1v cmUgY2xlYXIuDQoNCltNZWRdIFdvcmtzIGZvciBtZS4gDQoNCj4gDQo+ICAgIG8gIEEgcmVzb2x1 dGlvbiBtZWNoYW5pc20gYmFzZWQgb24gc3RyYWlnaHRmb3J3YXJkIE5hbWluZw0KPiBBdXRob3Jp dHkNCj4gICAgICAgUG9pbnRlciAoUy1OQVBUUikgcmVzb3VyY2UgcmVjb3JkcyBpbiB0aGUgRG9t YWluIE5hbWUgU3lzdGVtDQo+IChETlMpDQo+ICAgICAgIChTZWN0aW9uIDYpLg0KPiANCj4gIlN0 cmFpZ2h0Zm9yd2FyZCIgbmVlZHMgdG8gYmUgY2FwaXRhbGl6ZWQgaGVyZS4NCg0KW01lZF0gRml4 ZWQuIFRoYW5rcy4gDQoNCj4gDQo+IFNlY3Rpb24gNA0KPiANCj4gICAgd2lsbCBzdXBwb3J0IGEg bG9jYWwgY29uZmlndXJhdGlvbi4gIE1vcmUgc2FtcGxlcyBhcmUgZGlzY3Vzc2VkDQo+IGluDQo+ ICAgIFNlY3Rpb24gMzoNCj4gDQo+IG5pdDogcy86Ly4vDQoNCltNZWRdIE9LLg0KDQo+IA0KPiBT ZWN0aW9uIDUNCj4gDQo+ICAgIFRoZSBsaXN0IG9mIHRoZSBJUCBhZGRyZXNzZXMgcmV0dXJuZWQg YnkgREhDUCBzZXJ2ZXJzIGlzDQo+IHR5cGljYWxseQ0KPiAgICB1c2VkIHRvIGZlZWQgdGhlIERP VFMgc2VydmVyIHNlbGVjdGlvbiBwcm9jZWR1cmUgaW5jbHVkaW5nIHdoZW4NCj4gRE9UUw0KPiAg ICBhZ2VudHMgYXJlIHByb3ZpZGVkIHdpdGggcHJpbWFyeSBhbmQgYmFja3VwIElQIGFkZHJlc3Nl cyBvZiB0aGVpcg0KPiAgICBwZWVyIERPVFMgYWdlbnRzLiAgQW4gZXhhbXBsZSBvZiBET1RTIHNl cnZlciBzZWxlY3Rpb24gcHJvY2VkdXJlDQo+IGlzDQo+ICAgIHNwZWNpZmllZCBpbiBTZWN0aW9u IDQuMyBvZiBbUkZDODc4Ml0uDQo+IA0KPiBUaGUgcmVmZXJlbmNlZCBzZWN0aW9uIGluIDg3ODIg aXMgYWJvdXQgdGhlICJoYXBweSBleWViYWxscyIsIGkuZS4sDQo+IHBpY2tpbmcgYmV0d2VlbiBU Q1AvVURQIGFuZCBJUHY0L0lQdjYgLS0gaXQgZG9lc24ndCByZWFsbHkgc2VlbQ0KPiBpbnRlbmRl ZCB0byBjb3ZlciB0aGUgY2FzZSB3aGVyZSB5b3UgaGF2ZSB0byBwaWNrIGJldHdlbiBkaWZmZXJl bnQNCj4gYWN0dWFsIG5vZGVzLg0KDQpbTWVkXSBUaGF0IHRleHQgaXMgYWJvdXQgYW4gZXhhbXBs ZSBvZiBhZGRyZXNzIHNlbGVjdGlvbiBwcm9jZWR1cmUgKGluY2x1ZGluZyBiZXR3ZWVuIG5vZGVz OiB0aGluayBhYm91dCBhIGR1YWwgc3RhY2sgaG9zdCB0aGF0IHJlY2VpdmVzIGJvdGggdjQgYW5k IHY2IGNvbmZpZykuIEl0IGlzIHVzZWZ1bCBhcyBpdCByZWZlcnMgKGluZGlyZWN0bHkpIHRvIFJG QzY3MjQgd2hpY2ggYWxsb3dzIGZvciBjb25maWd1cmluZyBhIHByZWZlcmVuY2UgLi4uIA0KDQo+ IA0KPiBJJ20gYWxzbyBub3Qgc3VyZSBob3cgdGhlICJwcmltYXJ5IGFuZCBiYWNrdXAiIGlzIGlu dGVuZGVkIHRvIHdvcmssDQo+IGhlcmUuICBJcyB0aGUgInByb3ZpZGVkIHdpdGgiIHJlZmVycmlu ZyB0byAiYnkgREhDUCIgb3Igc29tZSBvdXQtb2YtDQo+IGJhbmQgY29uZmlndXJhdGlvbj8NCg0K W01lZF0gLi4uIEkgdGhvdWdodCB3ZSBoYWQgdGhpcyBhbHJlYWR5IGNvdmVyZWQgaW4gdGhlIHRl eHQsIGJ1dCBpdCBpc24ndC4gSSBhZGRlZCAiVGhlIGFkZHJlc3NlcyBhcmUgbGlzdGVkIGluIHRo ZSBvcmRlciBvZiBwcmVmZXJlbmNlIGZvciB1c2UgYnkgdGhlIERPVFMgYWdlbnQuIiBzbyB0aGF0 IGEgcHJlZmVyZW5jZSBpcyBzaWduYWxsZWQgYnkgdGhlIHNlcnZlciB0byB0aGUgYSByZXF1ZXN0 aW5nIERIQ1AgY2xpZW50Lg0KDQpUaGUgcHJpbWFyeSB3aWxsIGJlIGxpc3RlZCBmaXJzdC4gDQoN Cj4gDQo+IFNlY3Rpb24gOC4xDQo+IA0KPiAgICBjb25maWd1cmVkIG5hbWUuICBJZiB0aGUgRE9U UyBhZ2VudCBpcyBpbnN0cnVjdGVkIHRvIHRydXN0DQo+IHN1YmRvbWFpbnMNCj4gICAgb2YgdGhl IG5hbWVzIGluIHRoYXQgbGlzdCBhcyB3ZWxsLCBhIERPVFMgYWdlbnQgd2lsbCBhbHNvIGFjY2Vw dA0KPiBhDQo+ICAgIERIQ1AtZGlzY292ZXJlZCBuYW1lIGlmIHRoZSBsZWZ0LW1vc3QgbGFiZWwg b2YgdGhlIGRpc2NvdmVyZWQNCj4gbmFtZSBpcw0KPiAgICBtYXRjaGluZyBhIG5hbWUgaW4gdGhl IHByZS1jb25maWd1cmVkIGxpc3QuDQo+IA0KPiBJZiB0aGUgYWdlbnQgaXMgY29uZmlndXJlZCB0 byB0cnVzdCBzdWJkb21haW5zIG9mIHRoZSBjb25maWd1cmVkDQo+IGxpc3QsIHRoZW4gaW4gdGhl IGNhc2Ugd2hlcmUgdGhhdCBjb25maWd1cmF0aW9uIGlzIHJlbGV2YW50IGZvciB0aGUNCj4gYXR0 YWNrLCB0aGUgbGVmdC1tb3N0IGxhYmVsIHdpbGwgYmUgdGhlIChwYXJ0IG9mIHRoZSkgc3ViZG9t YWluDQo+IG5hbWUsIHdoaWNoIGlzIGV4cGxpY2l0bHkgbm90IG1hdGNoaW5nIHRoZSBwcmUtY29u ZmlndXJlZCBsaXN0IC0tDQo+IHRoZSByZW1haW5pbmcgYml0cyBhcmUgd2hhdCBtYXRjaC4NCj4g DQpbTWVkXSBDaGFuZ2VkIHRoZSB3b3JkaW5nIGFzIGZvbGxvd3M6DQoNCiJJZiB0aGUgRE9UUyBh Z2VudCBpcyBpbnN0cnVjdGVkIHRvIHRydXN0IHN1YmRvbWFpbnMgb2YgdGhlIG5hbWVzIGluIHRo YXQgbGlzdCBhcyB3ZWxsIChlLmcuLCAiKi5leGFtcGxlLmNvbSIpLCBhIERPVFMgYWdlbnQgd2ls bCBhY2NlcHQgYSBESENQLWRpc2NvdmVyZWQgbmFtZSB0aGF0IG1hdGNoZXMgYSBuYW1lIGluIHRo ZSBwcmUtY29uZmlndXJlZCBsaXN0IChlLmcuLCAiZG90cy0xLmV4YW1wbGUuY29tIiBvciAiZG90 cy0yLmV4YW1wbGUuY29tIikuIg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Oct 27 09:14: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 A60C43A11AC; Tue, 27 Oct 2020 09:14:49 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pO0nlVwcY2kD; Tue, 27 Oct 2020 09:14:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 354AF3A10DA; Tue, 27 Oct 2020 09:14:39 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09RGEWqV005445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 12:14:37 -0400 Date: Tue, 27 Oct 2020 09:14:32 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "draft-ietf-dots-server-discovery@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Message-ID: <20201027161432.GL39170@kduck.mit.edu> References: <160376439800.28769.11555549483055573494@ietfa.amsl.com> <30446_1603783506_5F97CB52_30446_33_1_787AE7BB302AE849A7480A190F8B9330315673E7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <30446_1603783506_5F97CB52_30446_33_1_787AE7BB302AE849A7480A190F8B9330315673E7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 16:14:55 -0000 Thanks, Med. Please go ahead and upload a -14 if you get the chance; most of the IESG will not start reviewing (for next week's telechat) until the end of this week. -Ben On Tue, Oct 27, 2020 at 07:25:06AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > An updated version is available at: https://tinyurl.com/dots-discovery-iesg > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > > Envoyé : mardi 27 octobre 2020 03:07 > > Ą : The IESG > > Cc : draft-ietf-dots-server-discovery@ietf.org; dots- > > chairs@ietf.org; dots@ietf.org; Valery Smyslov ; > > valery@smyslov.net > > Objet : Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: > > (with COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dots-server-discovery-13: Yes > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ > > > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Pulling in some follow-up from the directorate review comments... > > > > Section 3 > > > > o Resolving a DOTS server domain name offered by an upstream > > transit > > provider provisioned to a DOTS client into IP address(es) > > requires > > the use of the appropriate DNS resolvers; otherwise, resolving > > those names will fail. The use of protocols such as DHCP does > > allow associating provisioned DOTS server domain names with a > > list > > of DNS servers to be used for name resolution. Furthermore, > > DHCP > > allows directly provisioning IP addresses therefore avoiding > > the > > need for extra lookup delays. > > > > I wonder if using "providing" rather than "provisioning" for at > > least the last instance would be more clear. > > [Med] Works for me. > > > > > o A resolution mechanism based on straightforward Naming > > Authority > > Pointer (S-NAPTR) resource records in the Domain Name System > > (DNS) > > (Section 6). > > > > "Straightforward" needs to be capitalized here. > > [Med] Fixed. Thanks. > > > > > Section 4 > > > > will support a local configuration. More samples are discussed > > in > > Section 3: > > > > nit: s/:/./ > > [Med] OK. > > > > > Section 5 > > > > The list of the IP addresses returned by DHCP servers is > > typically > > used to feed the DOTS server selection procedure including when > > DOTS > > agents are provided with primary and backup IP addresses of their > > peer DOTS agents. An example of DOTS server selection procedure > > is > > specified in Section 4.3 of [RFC8782]. > > > > The referenced section in 8782 is about the "happy eyeballs", i.e., > > picking between TCP/UDP and IPv4/IPv6 -- it doesn't really seem > > intended to cover the case where you have to pick betwen different > > actual nodes. > > [Med] That text is about an example of address selection procedure (including between nodes: think about a dual stack host that receives both v4 and v6 config). It is useful as it refers (indirectly) to RFC6724 which allows for configuring a preference ... > > > > > I'm also not sure how the "primary and backup" is intended to work, > > here. Is the "provided with" referring to "by DHCP" or some out-of- > > band configuration? > > [Med] ... I thought we had this already covered in the text, but it isn't. I added "The addresses are listed in the order of preference for use by the DOTS agent." so that a preference is signalled by the server to the a requesting DHCP client. > > The primary will be listed first. > > > > > Section 8.1 > > > > configured name. If the DOTS agent is instructed to trust > > subdomains > > of the names in that list as well, a DOTS agent will also accept > > a > > DHCP-discovered name if the left-most label of the discovered > > name is > > matching a name in the pre-configured list. > > > > If the agent is configured to trust subdomains of the configured > > list, then in the case where that configuration is relevant for the > > attack, the left-most label will be the (part of the) subdomain > > name, which is explicitly not matching the pre-configured list -- > > the remaining bits are what match. > > > [Med] Changed the wording as follows: > > "If the DOTS agent is instructed to trust subdomains of the names in that list as well (e.g., "*.example.com"), a DOTS agent will accept a DHCP-discovered name that matches a name in the pre-configured list (e.g., "dots-1.example.com" or "dots-2.example.com")." > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Tue Oct 27 09:58: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 711C93A0CE2; Tue, 27 Oct 2020 09:58:31 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ztbKUIrBgQAy; Tue, 27 Oct 2020 09:58:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 725BC3A03AA; Tue, 27 Oct 2020 09:58:29 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09RGwM6A024385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 12:58:27 -0400 Date: Tue, 27 Oct 2020 09:58:22 -0700 From: Benjamin Kaduk To: draft-ietf-dots-signal-call-home.all@ietf.org Cc: dots@ietf.org Message-ID: <20201027165822.GO39170@kduck.mit.edu> References: <160337163947.12987.14997256042327860516@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160337163947.12987.14997256042327860516@ietfa.amsl.com> Archived-At: Subject: Re: [Dots] New Version Notification - draft-ietf-dots-signal-call-home-10.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, 27 Oct 2020 16:58:32 -0000 On Thu, Oct 22, 2020 at 06:00:39AM -0700, internet-drafts@ietf.org wrote: > > A new version (-10) has been submitted for draft-ietf-dots-signal-call-home: > https://www.ietf.org/archive/id/draft-ietf-dots-signal-call-home-10.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-10 Thanks for the updates; this all looks quite good. I have just a few editorial remarks on the new text (below), and the only issue keeping me from issuing an IETF LC is the IPR question (https://datatracker.ietf.org/ipr/3318/ appears in the IPR search for this document). I'm happy to do so if we have broad WG consensus to proceed even in light of the IPR report (or if the IPR report gets updated), but I don't remember anyone other than the authors replying on that topic yet. -Ben Section 5.3.1 The 'source-prefix' parameter is a mandatory attribute when the attack traffic information is signaled by a Call Home DOTS client (i.e., the Call Home scenario depicted in Figure 7). 'target-prefix' attribute MUST be included in the mitigation request signaling the attack information to a Call Home DOTS server. The 'target-uri' or nit: Start the second sentence with "The" (just like the third sentence). If the Call Home DOTS server rejects the mitigation request without waiting for a consent from the Call Home DOTS server domain administrator, the 'conflict-cause' set to '4' is returned in 4.09 (Conflict) sent back to the Call Home DOTS client. If the attack traffic information is identified by the Call Home DOTS server or the Call Home DOTS server domain administrator as legitimate traffic, the mitigation request is rejected with a 4.09 (Conflict) or a notification message with the 'conflict-clause' (Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the following new value: These two paragraphs seem to have a decent amount of overlap, and the first one also uses the conflict-cause value '4' before it's introduced by the second paragraph. I think we should be able to consolidate the two paragraphs. Section 5.3.2 Figure 10 depictes an example of a network provider that hosts a Call Home DOTS client and deploys a Carrier Grade NAT (CGN) between the DOTS client domain and DOTS server domain. In such case, nit: "cases" plural. From nobody Tue Oct 27 22:02: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 DBC5C3A0E91; Tue, 27 Oct 2020 22:02:37 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkbsqyBTlpDw; Tue, 27 Oct 2020 22:02:35 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 911C83A0E8C; Tue, 27 Oct 2020 22:02:35 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id h21so4028592iob.10; Tue, 27 Oct 2020 22:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yxYDFFntvEGkAg4DvE6zYqqOU3oJ6sG3bwjt2GkgDfk=; b=QniXULZaZMl3ZtZrFnLijlUaCWr1UDycmmBdFHzleKl/XM/iOaBmxoP/uJ0vyjz39s /6P2LOp/GbeUx7MJ2BtphPMavWOinX8BJJjicosAggVLSlFObW24NXqpVNpyVZKJP2eN mR/WT+cRicOzVAlXzH8GgU8N2tLczaH/ni5YiU9WsEg650+hX3TNC9Q1u46ZE+f1fxoz R6fm4b/1LovpoSXnqs1uzR5tm5HokppbyhnM0RU92jG2/FAdFJLczhAior4Zd7d1y+u1 YbzxOqcY2QY1UoXN4F4o8f2/g1TPMx8w/xt2hulm3DHCnlKQl0PvkRd86FZd2A1k+JgW 9D9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yxYDFFntvEGkAg4DvE6zYqqOU3oJ6sG3bwjt2GkgDfk=; b=USiin6V3FJi0GVqt1HYrKVKCxVOkqror4T5E7jAD20wdYeqPELwrBFsNidmfwANX76 XWNFZ9F/1N9ymZ28BZFO2+bV9vFBlAIzqNkgnzb8QfyWLi7l3hX2CTo+gmCbNcf03+Ud L5GDOgHmUjLJaEfmPJjTygz6yUdFDmaIzueW6CLej0Yi8dYge9cCp7vj+qXs0uMlFDIf OWXdOMtl9eg9fa+etXZU920A3Uy0925SDAIsrRhFKHYye/BNlXhWB6sdgIF6mhHtWm6E mpQRua5ZiZqypOGJDfhNrd6LZnyIDW49oIIKjEHwR8GaUBYDHepf+kSpfSg0Vp0p3If0 tr2w== X-Gm-Message-State: AOAM531ULvdF1n+VRvsetpA5GkoAy1+vNTZHmnDBqaBXldLv4O4PNf7G rO6ZiizbKIQ3DaQCAOmox0+kdysM/kd6hpsBBCo= X-Google-Smtp-Source: ABdhPJwvPLfdqPRlgZ7Pg++BUP4Zbyazs7geeFjr36mNFC5ApojQaS5ozY72YX2izxwlabbFw+5h3XE3078fTDKxMG0= X-Received: by 2002:a05:6602:14c9:: with SMTP id b9mr3093246iow.0.1603861354588; Tue, 27 Oct 2020 22:02:34 -0700 (PDT) MIME-Version: 1.0 References: <160337163947.12987.14997256042327860516@ietfa.amsl.com> <20201027165822.GO39170@kduck.mit.edu> In-Reply-To: <20201027165822.GO39170@kduck.mit.edu> From: tirumal reddy Date: Wed, 28 Oct 2020 10:32:23 +0530 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-dots-signal-call-home.all@ietf.org, dots@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f2f7d05b2b41299" Archived-At: Subject: Re: [Dots] New Version Notification - draft-ietf-dots-signal-call-home-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 05:02:38 -0000 --0000000000004f2f7d05b2b41299 Content-Type: text/plain; charset="UTF-8" Hi Ben, Please see inline On Tue, 27 Oct 2020 at 22:28, Benjamin Kaduk wrote: > On Thu, Oct 22, 2020 at 06:00:39AM -0700, internet-drafts@ietf.org wrote: > > > > A new version (-10) has been submitted for > draft-ietf-dots-signal-call-home: > > https://www.ietf.org/archive/id/draft-ietf-dots-signal-call-home-10.txt > > > > Sub state has been changed to AD Followup from Revised ID Needed > > > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ > > > > Diff from previous version: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-10 > > Thanks for the updates; this all looks quite good. I have just a few > editorial remarks on the new text (below), and the only issue keeping me > from issuing an IETF LC is the IPR question > (https://datatracker.ietf.org/ipr/3318/ appears in the IPR search for this > document). I'm happy to do so if we have broad WG consensus to proceed > even in light of the IPR report (or if the IPR report gets updated), but I > don't remember anyone other than the authors replying on that topic yet. > The IPR declaration will be updated to option "c) Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee" this week. Cheers, -Tiru > > -Ben > > > Section 5.3.1 > > The 'source-prefix' parameter is a mandatory attribute when the > attack traffic information is signaled by a Call Home DOTS client > (i.e., the Call Home scenario depicted in Figure 7). 'target-prefix' > attribute MUST be included in the mitigation request signaling the > attack information to a Call Home DOTS server. The 'target-uri' or > > nit: Start the second sentence with "The" (just like the third sentence). > > If the Call Home DOTS server rejects the mitigation request without > waiting for a consent from the Call Home DOTS server domain > administrator, the 'conflict-cause' set to '4' is returned in 4.09 > (Conflict) sent back to the Call Home DOTS client. > > If the attack traffic information is identified by the Call Home DOTS > server or the Call Home DOTS server domain administrator as > legitimate traffic, the mitigation request is rejected with a 4.09 > (Conflict) or a notification message with the 'conflict-clause' > (Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the following > new value: > > These two paragraphs seem to have a decent amount of overlap, and the > first one also uses the conflict-cause value '4' before it's introduced > by the second paragraph. I think we should be able to consolidate the > two paragraphs. > > Section 5.3.2 > > Figure 10 depictes an example of a network provider that hosts a Call > Home DOTS client and deploys a Carrier Grade NAT (CGN) between the > DOTS client domain and DOTS server domain. In such case, > > nit: "cases" plural. > > --0000000000004f2f7d05b2b41299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Please see inline
On = Tue, 27 Oct 2020 at 22:28, Benjamin Kaduk <kaduk@mit.edu> wrote:
On Thu, Oct 22, 2020 at 06:00:39AM -0700, internet-drafts@ietf.org = wrote:
>
> A new version (-10) has been submitted for draft-ietf-dots-signal-call= -home:
> https://www.ietf.org/arc= hive/id/draft-ietf-dots-signal-call-home-10.txt
>
> Sub state has been changed to AD Followup from Revised ID Needed
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/= doc/draft-ietf-dots-signal-call-home/
>
> Diff from previous version:
> https://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-dots-signal-call-home-10

Thanks for the updates; this all looks quite good.=C2=A0 I have just a few<= br> editorial remarks on the new text (below), and the only issue keeping me from issuing an IETF LC is the IPR question
(https://datatracker.ietf.org/ipr/3318/ appears in the IPR= search for this
document).=C2=A0 I'm happy to do so if we have broad WG consensus to pr= oceed
even in light of the IPR report (or if the IPR report gets updated), but I<= br> don't remember anyone other than the authors replying on that topic yet= .

The IPR declaration will be updated t= o option "c)=C2=A0Reasonable and Non-Discriminatory License to All Imp= lementers with Possible Royalty/Fee" this week.

Cheers,
-Tiru
=C2=A0

-Ben


Section 5.3.1

=C2=A0 =C2=A0The 'source-prefix' parameter is a mandatory attribute= when the
=C2=A0 =C2=A0attack traffic information is signaled by a Call Home DOTS cli= ent
=C2=A0 =C2=A0(i.e., the Call Home scenario depicted in Figure 7). 'targ= et-prefix'
=C2=A0 =C2=A0attribute MUST be included in the mitigation request signaling= the
=C2=A0 =C2=A0attack information to a Call Home DOTS server.=C2=A0 The '= target-uri' or

nit: Start the second sentence with "The" (just like the third se= ntence).

=C2=A0 =C2=A0If the Call Home DOTS server rejects the mitigation request wi= thout
=C2=A0 =C2=A0waiting for a consent from the Call Home DOTS server domain =C2=A0 =C2=A0administrator, the 'conflict-cause' set to '4'= is returned in 4.09
=C2=A0 =C2=A0(Conflict) sent back to the Call Home DOTS client.=C2=A0 =C2= =A0

=C2=A0 =C2=A0If the attack traffic information is identified by the Call Ho= me DOTS
=C2=A0 =C2=A0server or the Call Home DOTS server domain administrator as =C2=A0 =C2=A0legitimate traffic, the mitigation request is rejected with a = 4.09
=C2=A0 =C2=A0(Conflict) or a notification message with the 'conflict-cl= ause'
=C2=A0 =C2=A0(Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the foll= owing
=C2=A0 =C2=A0new value:

These two paragraphs seem to have a decent amount of overlap, and the
first one also uses the conflict-cause value '4' before it's in= troduced
by the second paragraph.=C2=A0 I think we should be able to consolidate the=
two paragraphs.

Section 5.3.2

=C2=A0 =C2=A0Figure 10 depictes an example of a network provider that hosts= a Call
=C2=A0 =C2=A0Home DOTS client and deploys a Carrier Grade NAT (CGN) between= the
=C2=A0 =C2=A0DOTS client domain and DOTS server domain.=C2=A0 In such case,=

nit: "cases" plural.

--0000000000004f2f7d05b2b41299-- From nobody Tue Oct 27 23:30:14 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C5D3A0FCE; Tue, 27 Oct 2020 23:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160386660183.31312.8155469556763111786@ietfa.amsl.com> Date: Tue, 27 Oct 2020 23:30:01 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-14.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, 28 Oct 2020 06:30:02 -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) Agent Discovery Authors : Mohamed Boucadair Tirumaleswar Reddy Filename : draft-ietf-dots-server-discovery-14.txt Pages : 25 Date : 2020-10-27 Abstract: This document specifies mechanisms to configure Distributed Denial of Service Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. Knowing the appropriate DOTS server for a given location can be useful to engage mitigation actions even in cases where the DOTS client cannot localize the attack, but only knows that some resources are under attack and that help is needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-server-discovery-14 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-14 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 Oct 27 23:58:41 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 E05753A0FDE; Tue, 27 Oct 2020 23:58:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160386832087.11906.8786034508872028743@ietfa.amsl.com> Date: Tue, 27 Oct 2020 23:58:40 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-call-home-11.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, 28 Oct 2020 06:58:41 -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) Signal Channel Call Home Authors : Tirumaleswar Reddy Mohamed Boucadair Jon Shallow Filename : draft-ietf-dots-signal-call-home-11.txt Pages : 42 Date : 2020-10-27 Abstract: This document specifies the DOTS signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client, and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- rfc8782-bis) Please update TBD/TBA statements with the assignments made by IANA to DOTS Signal Channel Call Home. Also, please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-11 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call-home-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-11 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 Oct 28 00:01: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 75DB33A1007; Wed, 28 Oct 2020 00:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVqKjLscOwbK; Wed, 28 Oct 2020 00:01:57 -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 ACFAD3A0F01; Wed, 28 Oct 2020 00:01:56 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4CLfdH31dRz5wDp; Wed, 28 Oct 2020 08:01:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603868515; bh=derWdFvNPGWVTBTVB+0JXPhsSAsymI6x8BFS5jIUVrw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ZVC3+eNDB2YtWnphTFpbyjHvl2dBe9RsOUI3vGZgBL8UFuJhT9FT7Wx2rqtIOo1op Z0xUvP6/8TN+u16EUj0k3cCMcPGcg39JTB2xvetGsjZGCImoK9MBMPBc8TEcaKwmNM p+ifM7ZGVAESEtfJs/BH1sy6vI9DmKas+gyDAMBSSbpK2VrwFhAC8CCvx1ENluE1zv RDOe2qA+C91BInHoi/r1jK/37Gm92mRnmWaA53TQ/qWl0R1znEY17lAXnn2wL7IFpC tNBiHxZPfLKXIPb0uEavZJ3Odp8ZsgSK16aVFK45coki5p+G+yvl/bhxHLrH6pNHbQ 8bUPZDnH5LAzA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4CLfdH2K87zDq7N; Wed, 28 Oct 2020 08:01:55 +0100 (CET) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-call-home.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: New Version Notification - draft-ietf-dots-signal-call-home-10.txt Thread-Index: AQHWrIJnnCvxTZfSjU23NDNC4wo1n6mslsPw Date: Wed, 28 Oct 2020 07:01:54 +0000 Message-ID: <20546_1603868515_5F991763_20546_225_1_787AE7BB302AE849A7480A190F8B933031568143@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160337163947.12987.14997256042327860516@ietfa.amsl.com> <20201027165822.GO39170@kduck.mit.edu> In-Reply-To: <20201027165822.GO39170@kduck.mit.edu> 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] New Version Notification - draft-ietf-dots-signal-call-home-10.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 07:01:58 -0000 Hi Ben, all,=20 A new version that fixes the points you raised is available online.=20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-call-home-11=20 Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: mardi 27 octobre 2020 17:58 > =C0=A0: draft-ietf-dots-signal-call-home.all@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: Re: New Version Notification - draft-ietf-dots-signal-call- > home-10.txt >=20 > On Thu, Oct 22, 2020 at 06:00:39AM -0700, internet-drafts@ietf.org > wrote: > > > > A new version (-10) has been submitted for draft-ietf-dots-signal- > call-home: > > https://www.ietf.org/archive/id/draft-ietf-dots-signal-call-home- > 10.tx > > t > > > > Sub state has been changed to AD Followup from Revised ID Needed > > > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ > > > > Diff from previous version: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-call- > home-10 >=20 > Thanks for the updates; this all looks quite good. I have just a > few editorial remarks on the new text (below), and the only issue > keeping me from issuing an IETF LC is the IPR question > (https://datatracker.ietf.org/ipr/3318/ appears in the IPR search > for this document). I'm happy to do so if we have broad WG > consensus to proceed even in light of the IPR report (or if the IPR > report gets updated), but I don't remember anyone other than the > authors replying on that topic yet. >=20 > -Ben >=20 >=20 > Section 5.3.1 >=20 > The 'source-prefix' parameter is a mandatory attribute when the > attack traffic information is signaled by a Call Home DOTS client > (i.e., the Call Home scenario depicted in Figure 7). 'target- > prefix' > attribute MUST be included in the mitigation request signaling > the > attack information to a Call Home DOTS server. The 'target-uri' > or >=20 > nit: Start the second sentence with "The" (just like the third > sentence). >=20 > If the Call Home DOTS server rejects the mitigation request > without > waiting for a consent from the Call Home DOTS server domain > administrator, the 'conflict-cause' set to '4' is returned in > 4.09 > (Conflict) sent back to the Call Home DOTS client. >=20 > If the attack traffic information is identified by the Call Home > DOTS > server or the Call Home DOTS server domain administrator as > legitimate traffic, the mitigation request is rejected with a > 4.09 > (Conflict) or a notification message with the 'conflict-clause' > (Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the > following > new value: >=20 > These two paragraphs seem to have a decent amount of overlap, and > the first one also uses the conflict-cause value '4' before it's > introduced by the second paragraph. I think we should be able to > consolidate the two paragraphs. >=20 > Section 5.3.2 >=20 > Figure 10 depictes an example of a network provider that hosts a > Call > Home DOTS client and deploys a Carrier Grade NAT (CGN) between > the > DOTS client domain and DOTS server domain. In such case, >=20 > nit: "cases" plural. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 28 10:08:42 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 C62B53A0140; Wed, 28 Oct 2020 10:08:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160390492080.31438.17646019336174981377@ietfa.amsl.com> Date: Wed, 28 Oct 2020 10:08:40 -0700 Archived-At: Subject: [Dots] IPR Disclosure McAfee LLC's Statement about IPR related to draft-ietf-dots-signal-call-home and draft-reddy-dots-home-network 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, 28 Oct 2020 17:08:41 -0000 Dear Tirumaleswar Reddy.K, Mohamed Boucadair, Jon Shallow: An IPR disclosure that pertains to your Internet-Draft entitled "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home" (draft-ietf-dots-signal-call-home) was submitted to the IETF Secretariat on 2020-10-28 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4405/). The title of the IPR disclosure is "McAfee LLC's Statement about IPR related to draft-ietf-dots-signal-call-home and draft-reddy-dots-home-network" Thank you IETF Secretariat From nobody Wed Oct 28 14:40:20 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 B7E043A09C3; Wed, 28 Oct 2020 14:40:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-dots-server-discovery@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , valery@smyslov.net X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160392121572.3395.6848068643884505857@ietfa.amsl.com> Date: Wed, 28 Oct 2020 14:40:15 -0700 Archived-At: Subject: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 21:40:16 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dots-server-discovery-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Overall discussion question (but not at blocking DISCUSS level): Does it make sense for DOTS clients to proactively discover appropriate DOTS servers *before* a DDoS attack hits, to avoid the issue of discovery being blocked by the attack that the client is trying to report? Should this document discuss that? Other comments, all minor: ā€” Section 1 ā€” This approach allows to reduce the impact of an attack and leads to more efficient defensive Nit: ā€œallows toā€ isnā€™t proper English, as it lacks a subject: ā€œallows toā€. I think the subject you want here is DOTS, so maybe this works?: NEW With this approach, DOTS can reduce the impact of an attack and lead to more efficient defensive END ā€” Section 2 ā€” The reader should be familiar with the terms defined in [RFC8811], [RFC3958], and [I-D.ietf-dots-signal-call-home]. I think this makes RFC 8811 and draft-ietf-dots-signal-call-home normative references, as they define require terminology. Certainly 8811 is normative in any case, as the architecture needs to be understood. ā€” Section 3 ā€” It is tempting to specify one single discovery mechanism for DOTS. Nevertheless, the analysis of the various use cases sketched in Nit: Ignore this if youā€™re happy with the text as it is, but I would remove the first sentence and just start this as ā€œAnalysis of the various use casesā€¦ā€. Please expand ā€œCPEā€ on first use ā€” especially as itā€™s confusingly and contradictorily described as ā€œCustomer Premises Equipmentā€ (provided by the operator) and ā€œCustomer Provided Equipmentā€ (not provided by the operator), so we need to know which you mean. ā€” Section 4 ā€” These may be specified either as IP addresses or the DNS name of a DOTS server. The first half of the sentence is plural and the second singular. Should both be plural, ā€œā€¦either as IP addresses or DNS names of DOTS servers.ā€ ? If itā€™s intentional that it can be multiple IP addresses but only one DNS name, it would be better to be more explicit about that. ā€” Section 5 ā€” and server while accommodating for the current best practices Nit: not ā€œaccommodating forā€: just ā€œaccommodatingā€. ā€” Section 5.1.1 ā€” o dots-agent-name: A fully qualified domain name of the peer DOTS agent. This field is formatted as specified in Section 10 of [RFC8415]. As all Section 10 of 8415 does is send us to Section 3.1 of 1035, why not just point to the latter directly, rather than making the reader follow an extra reference? And it wouldnā€™t be bad to append to the ā€œan exampleā€ sentence as follows: NEW An example of the dots-agent-name encoding is shown in Figure 4. This example conveys the FQDN "dots.example.com.ā€, and the resulting Option-length field is 18. END From nobody Wed Oct 28 16:48: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 9CC963A08CF; Wed, 28 Oct 2020 16:47:56 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 lWb19eNQCqeP; Wed, 28 Oct 2020 16:47:55 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1A4993A08C4; Wed, 28 Oct 2020 16:47:54 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09SNllsX005903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 19:47:51 -0400 Date: Wed, 28 Oct 2020 16:47:46 -0700 From: Benjamin Kaduk To: Barry Leiba Cc: The IESG , dots-chairs@ietf.org, valery@smyslov.net, draft-ietf-dots-server-discovery@ietf.org, dots@ietf.org Message-ID: <20201028234746.GS39170@kduck.mit.edu> References: <160392121572.3395.6848068643884505857@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160392121572.3395.6848068643884505857@ietfa.amsl.com> Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 23:47:57 -0000 Hi Barry, On Wed, Oct 28, 2020 at 02:40:15PM -0700, Barry Leiba via Datatracker wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Overall discussion question (but not at blocking DISCUSS level): > Does it make sense for DOTS clients to proactively discover appropriate DOTS > servers *before* a DDoS attack hits, to avoid the issue of discovery being > blocked by the attack that the client is trying to report? Should this > document discuss that? And here I had assumed that this was so obvious so as to not need mentioning. Apparently not; let's go ahead and mention this explicitly. > Other comments, all minor: Thanks for those. -Ben From nobody Wed Oct 28 23:55: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 7A6A53A0920; Wed, 28 Oct 2020 23:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynv94JnCKAN3; Wed, 28 Oct 2020 23:55:23 -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 B9B2A3A08CF; Wed, 28 Oct 2020 23:55:22 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4CMGRF0TqMz5vvs; Thu, 29 Oct 2020 07:55:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603954521; bh=Mnoy3JPj/r/bS9orX0WD73EUeJDIkLiQPo6ea6NwCIQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=h1u3b0oBUn6fcrC0NVMIgUWY6nFEahwB+mGPvkizVZfekcMlqJ3TBTUFjK93U7eoI IKvIU1BtuQKIADq/7yfchjd8xFLWZFR0wnyAAhA3s75+xete/fwRpZt2xvxCpGTrP8 hMV5ENz3BOBJAUeA8kVvMtF2LvLyAwwF+95P6TE5ikaxAo+fcCnyHfBGxTYlCP5tyw piDcgCX6wra5ChnU5wZcBT0ME7dbwySuQBHxbFkyQDm5Cg55pe1w6VzHIAdXgrrlCw /atHfZPlOlsOfg6wMRbSnapfq+ikGpVZrhiWG4zczRJqCQuBV33Tpuuf7kd9/XqjkE AKIiUczez+mIQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4CMGRD6mjVzFpWf; Thu, 29 Oct 2020 07:55:20 +0100 (CET) From: To: Barry Leiba , The IESG CC: "draft-ietf-dots-server-discovery@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) Thread-Index: AQHWrXLu59qgZV3TGUSV9ZZIRKrnyKmuIcAQ Date: Thu, 29 Oct 2020 06:55:20 +0000 Message-ID: <24589_1603954521_5F9A6758_24589_207_1_787AE7BB302AE849A7480A190F8B933031568E35@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160392121572.3395.6848068643884505857@ietfa.amsl.com> In-Reply-To: <160392121572.3395.6848068643884505857@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 06:55:24 -0000 SGkgQmFycnksIA0KDQpUaGFua3MgeW91IGZvciB0aGUgY29tbWVudHMuDQoNCkkgdXBkYXRlZCB0 aGUgZHJhZnQgdG8gYWRkcmVzcyB0aGUgcmV2aWV3LiBZb3UgY2FuIHRyYWNrIHRoZSBjaGFuZ2Vz IGF0OiBodHRwczovL3Rpbnl1cmwuY29tL2RvdHMtZGlzY292ZXJ5LWllc2cuIA0KDQpQbGVhc2Ug c2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiBCYXJyeSBMZWliYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5 QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDI4IG9jdG9icmUgMjAyMCAyMjo0MA0K PiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3Rz LXNlcnZlci1kaXNjb3ZlcnlAaWV0Zi5vcmc7IGRvdHMtDQo+IGNoYWlyc0BpZXRmLm9yZzsgZG90 c0BpZXRmLm9yZzsgVmFsZXJ5IFNteXNsb3YgPHZhbGVyeUBzbXlzbG92Lm5ldD47DQo+IHZhbGVy eUBzbXlzbG92Lm5ldA0KPiBPYmpldMKgOiBCYXJyeSBMZWliYSdzIE5vIE9iamVjdGlvbiBvbiBk cmFmdC1pZXRmLWRvdHMtc2VydmVyLQ0KPiBkaXNjb3ZlcnktMTQ6ICh3aXRoIENPTU1FTlQpDQo+ IA0KPiBCYXJyeSBMZWliYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCj4gZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci1kaXNjb3ZlcnktMTQ6IE5vIE9iamVjdGlv bg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8NCj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+IGN1dCB0aGlzIGludHJvZHVjdG9yeSBw YXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+IGZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWRvdHMtc2VydmVyLWRpc2NvdmVyeS8NCj4gDQo+IA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gDQo+IE92 ZXJhbGwgZGlzY3Vzc2lvbiBxdWVzdGlvbiAoYnV0IG5vdCBhdCBibG9ja2luZyBESVNDVVNTIGxl dmVsKToNCj4gRG9lcyBpdCBtYWtlIHNlbnNlIGZvciBET1RTIGNsaWVudHMgdG8gcHJvYWN0aXZl bHkgZGlzY292ZXINCj4gYXBwcm9wcmlhdGUgRE9UUyBzZXJ2ZXJzICpiZWZvcmUqIGEgRERvUyBh dHRhY2sgaGl0cywgdG8gYXZvaWQgdGhlDQo+IGlzc3VlIG9mIGRpc2NvdmVyeSBiZWluZyBibG9j a2VkIGJ5IHRoZSBhdHRhY2sgdGhhdCB0aGUgY2xpZW50IGlzDQo+IHRyeWluZyB0byByZXBvcnQ/ ICBTaG91bGQgdGhpcyBkb2N1bWVudCBkaXNjdXNzIHRoYXQ/DQo+IA0KDQpbTWVkXSBUaGlzIGlz IGFscmVhZHkgY292ZXJlZCBpbiB0aGUgdGV4dCBhcyB0aGUgZGlzY292ZXJ5IGlzIHRyaWdnZXJl ZCBieSBuZXcgbmV0d29yayBhdHRhY2htZW50cyAod2hpY2ggaW5jbHVkZXMgYm9vdHN0cmFwcGlu ZykuIFRoZSBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gaXMgdGh1cyBhdmFpbGFibGUgaW5kZXBlbmRl bnRseSBvZiB0aGUgYXR0YWNrIGNvbmRpdGlvbnMuIA0KDQo+IE90aGVyIGNvbW1lbnRzLCBhbGwg bWlub3I6DQo+IA0KPiDigJQgU2VjdGlvbiAxIOKAlA0KPiANCj4gICAgVGhpcyBhcHByb2FjaCBh bGxvd3MgdG8NCj4gICAgcmVkdWNlIHRoZSBpbXBhY3Qgb2YgYW4gYXR0YWNrIGFuZCBsZWFkcyB0 byBtb3JlIGVmZmljaWVudA0KPiBkZWZlbnNpdmUNCj4gDQo+IE5pdDog4oCcYWxsb3dzIHRv4oCd IGlzbuKAmXQgcHJvcGVyIEVuZ2xpc2gsIGFzIGl0IGxhY2tzIGEgc3ViamVjdDoNCj4g4oCcYWxs b3dzIDxzb21lDQo+IGVudGl0eT4gdG/igJ0uICBJIHRoaW5rIHRoZSBzdWJqZWN0IHlvdSB3YW50 IGhlcmUgaXMgRE9UUywgc28gbWF5YmUNCj4gdGhpcyB3b3Jrcz86DQo+IA0KPiBORVcNCj4gICAg V2l0aCB0aGlzIGFwcHJvYWNoLCBET1RTIGNhbg0KPiAgICByZWR1Y2UgdGhlIGltcGFjdCBvZiBh biBhdHRhY2sgYW5kIGxlYWQgdG8gbW9yZSBlZmZpY2llbnQNCj4gZGVmZW5zaXZlIEVORA0KPiAN Cg0KW01lZF0gRml4ZWQuIFRoYW5rcy4NCg0KPiDigJQgU2VjdGlvbiAyIOKAlA0KPiANCj4gICAg VGhlIHJlYWRlciBzaG91bGQgYmUgZmFtaWxpYXIgd2l0aCB0aGUgdGVybXMgZGVmaW5lZCBpbg0K PiBbUkZDODgxMV0sDQo+ICAgIFtSRkMzOTU4XSwgYW5kIFtJLUQuaWV0Zi1kb3RzLXNpZ25hbC1j YWxsLWhvbWVdLg0KPiANCj4gSSB0aGluayB0aGlzIG1ha2VzIFJGQyA4ODExIGFuZCBkcmFmdC1p ZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZQ0KPiBub3JtYXRpdmUgcmVmZXJlbmNlcywgYXMgdGhl eSBkZWZpbmUgcmVxdWlyZSB0ZXJtaW5vbG9neS4gIENlcnRhaW5seQ0KPiA4ODExIGlzIG5vcm1h dGl2ZSBpbiBhbnkgY2FzZSwgYXMgdGhlIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBiZQ0KPiB1bmRl cnN0b29kLg0KPiANCg0KW01lZF0gQXMgd2UgZG9uJ3QgZGVhbCB3aXRoIGhvdyBET1RTIHNlc3Np b25zIGFyZSBoYW5kbGVkIG5vciB3ZSBpbnRlcmZlcmUgd2l0aCB0aGUgaW50ZXJuYWwgRE9UUyBz aWduYWxsaW5nIG1hY2hpbmVyeSwgd2UgZG9uJ3QgY2l0ZSA4ODExIChidXQgYWxzbyA4NzgyLCA4 NzgzKSBhcyBub3JtYXRpdmUgb25lcy4gT2YgY291cnNlLCBoYXZpbmcgdGhlIHJlcXVpcmVkIGJh Y2tncm91bmQgaXMgdXNlZnVsIGJ1dCBpbXBsZW1lbnRpbmcgdGhlIGRpc2NvdmVyeSBwcm9jZXNz IGRvZXMgbm90IHJlcXVpcmUgdGhlc2UgcGllY2VzLg0KDQpJIHVuZGVyc3RhbmQgdGhlIHJlZmVy ZW5jZXMgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gbWF5IHN1Z2dlc3QgdGhhdCBrbm93bGVk Z2UgaXMgcmVxdWlyZWQuIFRvIGF2b2lkIHRoYXQsIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uIGlz IHVwZGF0ZWQgdG8gbGlzdCB0aGUgdGVybXMgdXNlZCBpbiB0aGUgZG9jdW1lbnQuIA0KDQo+IOKA lCBTZWN0aW9uIDMg4oCUDQo+IA0KPiAgICBJdCBpcyB0ZW1wdGluZyB0byBzcGVjaWZ5IG9uZSBz aW5nbGUgZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3INCj4gRE9UUy4NCj4gICAgTmV2ZXJ0aGVsZXNz LCB0aGUgYW5hbHlzaXMgb2YgdGhlIHZhcmlvdXMgdXNlIGNhc2VzIHNrZXRjaGVkIGluDQo+IA0K PiBOaXQ6IElnbm9yZSB0aGlzIGlmIHlvdeKAmXJlIGhhcHB5IHdpdGggdGhlIHRleHQgYXMgaXQg aXMsIGJ1dCBJIHdvdWxkDQo+IHJlbW92ZSB0aGUgZmlyc3Qgc2VudGVuY2UgYW5kIGp1c3Qgc3Rh cnQgdGhpcyBhcyDigJxBbmFseXNpcyBvZiB0aGUNCj4gdmFyaW91cyB1c2UgY2FzZXPigKbigJ0u DQoNCltNZWRdIFdlbnQgd2l0aCB5b3VyIHByb3Bvc2FsLiANCg0KPiANCj4gUGxlYXNlIGV4cGFu ZCDigJxDUEXigJ0gb24gZmlyc3QgdXNlIOKAlCBlc3BlY2lhbGx5IGFzIGl04oCZcyBjb25mdXNp bmdseQ0KPiBhbmQgY29udHJhZGljdG9yaWx5IGRlc2NyaWJlZCBhcyDigJxDdXN0b21lciBQcmVt aXNlcyBFcXVpcG1lbnTigJ0NCj4gKHByb3ZpZGVkIGJ5IHRoZQ0KPiBvcGVyYXRvcikgYW5kIOKA nEN1c3RvbWVyIFByb3ZpZGVkIEVxdWlwbWVudOKAnSAobm90IHByb3ZpZGVkIGJ5IHRoZQ0KPiBv cGVyYXRvciksIHNvIHdlIG5lZWQgdG8ga25vdyB3aGljaCB5b3UgbWVhbi4NCj4gDQoNCltNZWRd IERvbmUuIA0KDQo+IOKAlCBTZWN0aW9uIDQg4oCUDQo+IA0KPiAgICBUaGVzZSBtYXkgYmUNCj4g ICAgc3BlY2lmaWVkIGVpdGhlciBhcyBJUCBhZGRyZXNzZXMgb3IgdGhlIEROUyBuYW1lIG9mIGEg RE9UUw0KPiAgICBzZXJ2ZXIuDQo+IA0KPiBUaGUgZmlyc3QgaGFsZiBvZiB0aGUgc2VudGVuY2Ug aXMgcGx1cmFsIGFuZCB0aGUgc2Vjb25kIHNpbmd1bGFyLg0KPiBTaG91bGQgYm90aCBiZSBwbHVy YWwsIOKAnOKApmVpdGhlciBhcyBJUCBhZGRyZXNzZXMgb3IgRE5TIG5hbWVzIG9mIERPVFMNCj4g c2VydmVycy7igJ0gPyAgSWYgaXTigJlzIGludGVudGlvbmFsIHRoYXQgaXQgY2FuIGJlIG11bHRp cGxlIElQDQo+IGFkZHJlc3NlcyBidXQgb25seSBvbmUgRE5TIG5hbWUsDQoNCltNZWRdIEkgY29u ZmlybS4NCg0KIGl0IHdvdWxkIGJlIGJldHRlciB0byBiZSBtb3JlDQo+IGV4cGxpY2l0IGFib3V0 IHRoYXQuDQo+IA0KDQpbTWVkXSBDaGFuZ2VkIHRvICJhIGxpc3Qgb2YgSVAgYWRkcmVzc2VzIiAN Cg0KPiDigJQgU2VjdGlvbiA1IOKAlA0KPiANCj4gICAgYW5kIHNlcnZlciB3aGlsZSBhY2NvbW1v ZGF0aW5nIGZvciB0aGUgY3VycmVudCBiZXN0IHByYWN0aWNlcw0KPiANCj4gTml0OiBub3Qg4oCc YWNjb21tb2RhdGluZyBmb3LigJ06IGp1c3Qg4oCcYWNjb21tb2RhdGluZ+KAnS4NCg0KW01lZF0g Rml4ZWQuIA0KDQo+IA0KPiDigJQgU2VjdGlvbiA1LjEuMSDigJQNCj4gDQo+ICAgIG8gIGRvdHMt YWdlbnQtbmFtZTogQSBmdWxseSBxdWFsaWZpZWQgZG9tYWluIG5hbWUgb2YgdGhlIHBlZXINCj4g RE9UUw0KPiAgICAgICBhZ2VudC4gIFRoaXMgZmllbGQgaXMgZm9ybWF0dGVkIGFzIHNwZWNpZmll ZCBpbiBTZWN0aW9uIDEwIG9mDQo+ICAgICAgIFtSRkM4NDE1XS4NCj4gDQo+IEFzIGFsbCBTZWN0 aW9uIDEwIG9mIDg0MTUgZG9lcyBpcyBzZW5kIHVzIHRvIFNlY3Rpb24gMy4xIG9mIDEwMzUsDQo+ IHdoeSBub3QganVzdCBwb2ludCB0byB0aGUgbGF0dGVyIGRpcmVjdGx5LCByYXRoZXIgdGhhbiBt YWtpbmcgdGhlDQo+IHJlYWRlciBmb2xsb3cgYW4gZXh0cmEgcmVmZXJlbmNlPw0KPiANCj4gQW5k IGl0IHdvdWxkbuKAmXQgYmUgYmFkIHRvIGFwcGVuZCB0byB0aGUg4oCcYW4gZXhhbXBsZeKAnSBz ZW50ZW5jZSBhcw0KPiBmb2xsb3dzOg0KPiANCj4gTkVXDQo+ICAgIEFuIGV4YW1wbGUgb2YgdGhl IGRvdHMtYWdlbnQtbmFtZSBlbmNvZGluZyBpcyBzaG93biBpbiBGaWd1cmUgNC4NCj4gICAgVGhp cyBleGFtcGxlIGNvbnZleXMgdGhlIEZRRE4gImRvdHMuZXhhbXBsZS5jb20u4oCdLCBhbmQgdGhl DQo+ICAgIHJlc3VsdGluZyBPcHRpb24tbGVuZ3RoIGZpZWxkIGlzIDE4Lg0KPiBFTkQNCj4gDQoN CltNZWRdIEFncmVlLiBEb25lLiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu Oct 29 06:08: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 918863A0808; Thu, 29 Oct 2020 06:08:14 -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, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 nY19fKyujLTr; Thu, 29 Oct 2020 06:08:13 -0700 (PDT) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (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 DB5CD3A0AF7; Thu, 29 Oct 2020 06:08:12 -0700 (PDT) Received: by mail-vk1-f176.google.com with SMTP id m3so671438vki.12; Thu, 29 Oct 2020 06:08:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WKfAxvqY3c2Ta8bufUsfRwgTkJinA/imOhNTMXoLT84=; b=SLjghetZvnJaeBIVONm8DXDXE6vh2C2fL1Q0Q39iqIdPaUN7LkExDuXuKmkCAyqBgy +aOUnxqQGtabGKcEgtVT3vzU0jWYytawONp70PqCxTS4F/EsmX/yWULdIsyvlf48CK3E ohO9D3wcgSFHitZGNjlU8z8hd5wKlUt4bz778hYTE6N0nmt6HvNlNMlwntXmxoYBOUL3 mYgiSxq2OB5va7OyiNRIJPM0Zu1H+Shg9wZEsNwdxiZS+VLeJaG632xETij5UlCSBZ8v 3hCTqLrWflGOd/UIJ+pPUFULcGproga8Y7eLbNUk/1cWbEhAbtWyyrsnNhZbr57IPZ2X qCXQ== X-Gm-Message-State: AOAM530wv2EYztWOlP0tcSLZOist1hWh1wvSF01I27ul9KvGh0iEuedN nwdCMNVK4Uj1QdqeqACMWmwnThvZWQjyyq09H7o= X-Google-Smtp-Source: ABdhPJxGPlAQqYlLXehqduA5LvsglWB38x3iN5SpXZ9w7UTJxwfLGS5x72z+gDMOp1wcCoIqUPnnhNAwM6as8wraSd0= X-Received: by 2002:a1f:a344:: with SMTP id m65mr2724535vke.23.1603976891670; Thu, 29 Oct 2020 06:08:11 -0700 (PDT) MIME-Version: 1.0 References: <160392121572.3395.6848068643884505857@ietfa.amsl.com> <24589_1603954521_5F9A6758_24589_207_1_787AE7BB302AE849A7480A190F8B933031568E35@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <24589_1603954521_5F9A6758_24589_207_1_787AE7BB302AE849A7480A190F8B933031568E35@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Barry Leiba Date: Thu, 29 Oct 2020 09:08:00 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-dots-server-discovery@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 13:08:15 -0000 Hi, Med, and many thanks for making the changes and addressing my comments. > > Overall discussion question (but not at blocking DISCUSS level): > > Does it make sense for DOTS clients to proactively discover > > appropriate DOTS servers *before* a DDoS attack hits, to avoid the > > issue of discovery being blocked by the attack that the client is > > trying to report? Should this document discuss that? > > [Med] This is already covered in the text as the discovery is triggered by new network > attachments (which includes bootstrapping). The discovery information is thus available > independently of the attack conditions. Indeed, so the list at the end of Section 4 implies, and that ought to be enough. Still, may I ask for one more minor change, which I think makes it just a tad more explicit? In the lead-in to the list: OLD The discovery method is reiterated by a DOTS agent upon the following events: NEW The discovery method is performed upon attachment to a network, and is reiterated by a DOTS agent upon the following events: END > I understand the references in the terminology section may suggest that knowledge is > required. To avoid that, the terminology section is updated to list the terms used in the > document. I looked at the update, and that works for me; thanks! Barry From nobody Thu Oct 29 06:30: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 363723A09EE; Thu, 29 Oct 2020 06:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opGbcd-muFaH; Thu, 29 Oct 2020 06:29:59 -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 766543A09F4; Thu, 29 Oct 2020 06:29:58 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4CMRBY0zJjzygD; Thu, 29 Oct 2020 14:29:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603978197; bh=0/ntQO/OwPz7CeuvmkgoXmOTZNjF2ipPa0/eAwpNLF0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ldaNLpBedXPq33mW9i3sVul4ihqHt3EG2LE0Lz0O2Yhq45oxzhz2ay5Sb40vst+jb goUfzkj17hX1QeIun9I0E35MKsZWG4PXPfUMdwxy5IVE3Y7fLfCnZh72uh4C97c3gX pGWx8zNgU6d+Z3RBlIxfOqSG+VYKPEzO2U462F9Yro3yJiqRmKhX+xJkBAGJiwlA+K Wg/8ohQj1MbkyTJos6cqHQUS3/Wm25qP1XXgqN3LBGmauIpQFEbrBWs00n0SFZHtM8 I73FY+QBhG+F5pLZza+ReotqQ3aWc7/7MwgmAqKfG/U/oiRqCWkU+Z8dEZ8us05eqW /Brl7GqnHH29g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4CMRBX637jzDq7B; Thu, 29 Oct 2020 14:29:56 +0100 (CET) From: To: Barry Leiba CC: The IESG , "draft-ietf-dots-server-discovery@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Thread-Topic: Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) Thread-Index: AQHWrfSPHZmC4LzlMUy3dfzTT+xCYqmuksLg Date: Thu, 29 Oct 2020 13:29:55 +0000 Message-ID: <25842_1603978196_5F9AC3D4_25842_315_1_787AE7BB302AE849A7480A190F8B93303156929B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160392121572.3395.6848068643884505857@ietfa.amsl.com> <24589_1603954521_5F9A6758_24589_207_1_787AE7BB302AE849A7480A190F8B933031568E35@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 13:30:02 -0000 UmUtLA0KDQpTdXJlLiBQbGVhc2UgY2hlY2sgdGhlIHVwZGF0ZSBhdDogaHR0cHM6Ly90aW55dXJs LmNvbS9kb3RzLWRpc2NvdmVyeS1pZXNnICANCg0KVGhhbmsgeW91LiANCg0KQ2hlZXJzLA0KTWVk DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEJhcnJ5IExlaWJhIFtt YWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmddDQo+IEVudm95w6nCoDogamV1ZGkgMjkgb2N0 b2JyZSAyMDIwIDE0OjA4DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IENjwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn PjsgZHJhZnQtaWV0Zi1kb3RzLXNlcnZlci0NCj4gZGlzY292ZXJ5QGlldGYub3JnOyBkb3RzLWNo YWlyc0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgVmFsZXJ5DQo+IFNteXNsb3YgPHZhbGVyeUBz bXlzbG92Lm5ldD4NCj4gT2JqZXTCoDogUmU6IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0aW9uIG9u IGRyYWZ0LWlldGYtZG90cy1zZXJ2ZXItDQo+IGRpc2NvdmVyeS0xNDogKHdpdGggQ09NTUVOVCkN Cj4gDQo+IEhpLCBNZWQsIGFuZCBtYW55IHRoYW5rcyBmb3IgbWFraW5nIHRoZSBjaGFuZ2VzIGFu ZCBhZGRyZXNzaW5nIG15DQo+IGNvbW1lbnRzLg0KPiANCj4gPiA+IE92ZXJhbGwgZGlzY3Vzc2lv biBxdWVzdGlvbiAoYnV0IG5vdCBhdCBibG9ja2luZyBESVNDVVNTIGxldmVsKToNCj4gPiA+IERv ZXMgaXQgbWFrZSBzZW5zZSBmb3IgRE9UUyBjbGllbnRzIHRvIHByb2FjdGl2ZWx5IGRpc2NvdmVy DQo+ID4gPiBhcHByb3ByaWF0ZSBET1RTIHNlcnZlcnMgKmJlZm9yZSogYSBERG9TIGF0dGFjayBo aXRzLCB0byBhdm9pZA0KPiB0aGUNCj4gPiA+IGlzc3VlIG9mIGRpc2NvdmVyeSBiZWluZyBibG9j a2VkIGJ5IHRoZSBhdHRhY2sgdGhhdCB0aGUgY2xpZW50DQo+IGlzDQo+ID4gPiB0cnlpbmcgdG8g cmVwb3J0PyAgU2hvdWxkIHRoaXMgZG9jdW1lbnQgZGlzY3VzcyB0aGF0Pw0KPiA+DQo+ID4gW01l ZF0gVGhpcyBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gdGhlIHRleHQgYXMgdGhlIGRpc2NvdmVyeSBp cw0KPiA+IHRyaWdnZXJlZCBieSBuZXcgbmV0d29yayBhdHRhY2htZW50cyAod2hpY2ggaW5jbHVk ZXMNCj4gYm9vdHN0cmFwcGluZykuDQo+ID4gVGhlIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBpcyB0 aHVzIGF2YWlsYWJsZSBpbmRlcGVuZGVudGx5IG9mIHRoZQ0KPiBhdHRhY2sgY29uZGl0aW9ucy4N Cj4gDQo+IEluZGVlZCwgc28gdGhlIGxpc3QgYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDQgaW1wbGll cywgYW5kIHRoYXQgb3VnaHQNCj4gdG8gYmUgZW5vdWdoLg0KPiANCj4gU3RpbGwsIG1heSBJIGFz ayBmb3Igb25lIG1vcmUgbWlub3IgY2hhbmdlLCB3aGljaCBJIHRoaW5rIG1ha2VzIGl0DQo+IGp1 c3QgYSB0YWQgbW9yZSBleHBsaWNpdD8gIEluIHRoZSBsZWFkLWluIHRvIHRoZSBsaXN0Og0KPiAN Cj4gT0xEDQo+ICAgIFRoZSBkaXNjb3ZlcnkgbWV0aG9kIGlzIHJlaXRlcmF0ZWQgYnkgYSBET1RT IGFnZW50IHVwb24gdGhlDQo+IGZvbGxvd2luZw0KPiAgICBldmVudHM6DQo+IA0KPiBORVcNCj4g ICAgVGhlIGRpc2NvdmVyeSBtZXRob2QgaXMgcGVyZm9ybWVkIHVwb24gYXR0YWNobWVudCB0byBh IG5ldHdvcmssDQo+IGFuZCBpcw0KPiAgICByZWl0ZXJhdGVkIGJ5IGEgRE9UUyBhZ2VudCB1cG9u IHRoZSBmb2xsb3dpbmcgZXZlbnRzOg0KPiANCj4gRU5EDQo+IA0KPiA+IEkgdW5kZXJzdGFuZCB0 aGUgcmVmZXJlbmNlcyBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBtYXkgc3VnZ2VzdA0KPiA+ IHRoYXQga25vd2xlZGdlIGlzIHJlcXVpcmVkLiBUbyBhdm9pZCB0aGF0LCB0aGUgdGVybWlub2xv Z3kgc2VjdGlvbg0KPiBpcw0KPiA+IHVwZGF0ZWQgdG8gbGlzdCB0aGUgdGVybXMgdXNlZCBpbiB0 aGUgZG9jdW1lbnQuDQo+IA0KPiBJIGxvb2tlZCBhdCB0aGUgdXBkYXRlLCBhbmQgdGhhdCB3b3Jr cyBmb3IgbWU7IHRoYW5rcyENCj4gDQo+IEJhcnJ5DQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Thu Oct 29 07:16: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 BDE4C3A0B15; Thu, 29 Oct 2020 07:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, 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 JNm-KN1E5nr1; Thu, 29 Oct 2020 07:16:20 -0700 (PDT) Received: from mail-vs1-f68.google.com (mail-vs1-f68.google.com [209.85.217.68]) (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 54A243A0B10; Thu, 29 Oct 2020 07:16:20 -0700 (PDT) Received: by mail-vs1-f68.google.com with SMTP id b4so1602407vsd.4; Thu, 29 Oct 2020 07:16:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ag+tGiDIGw3toVeXLTQwUYDJmEESacOVuc2MzRkfviw=; b=ZB/ClH1ZNfZ/FBxLIYZKh2XkIXvVd6NLxjpjwV8hNjNxRRBwmjrb7J7wyDSYqJ9Jw2 +0lPLbEJvNSD8H1bPbOWRcgSZjTmzv1XMa7nDP1V3cUqBM9B3dtqpzG755LHgpHrpdRP MFlIGlSQ5mxA9rahqpG3Js4d6xfNnEQncWrBtF2cTTUFLv7wlyXITOOuyIj8cmMl3S64 l1yn4mP+Lr+HwPIXmc31rKZ1drvQ16o9FnjUEC7gTL+T+9ajErqyDuUyFpzuBpTnADje 947KRPVAZhUH0QTs0ZUo/rfceoGtRpcPo5CCdIO5nJRpsclxvhVQn2i6Re98HkHqbxGz Hscw== X-Gm-Message-State: AOAM5337xe4SLmDJojVTm+t23yx9rkWvcvSmesApTRx/zHhJXlzDQiiG G9QsU7gsbzmDIh/GYjJ25VWXKXu18Y/1vThQiq8= X-Google-Smtp-Source: ABdhPJxjpcaE56STzXNX5IMvj06oulktfYeHGJ3qirB5x8dMxphK23laKI3dnYUFRNIEsSDQAYk63t6KXTsdCvsPaE4= X-Received: by 2002:a05:6102:115c:: with SMTP id j28mr3375541vsg.14.1603980979267; Thu, 29 Oct 2020 07:16:19 -0700 (PDT) MIME-Version: 1.0 References: <160392121572.3395.6848068643884505857@ietfa.amsl.com> <24589_1603954521_5F9A6758_24589_207_1_787AE7BB302AE849A7480A190F8B933031568E35@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <25842_1603978196_5F9AC3D4_25842_315_1_787AE7BB302AE849A7480A190F8B93303156929B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <25842_1603978196_5F9AC3D4_25842_315_1_787AE7BB302AE849A7480A190F8B93303156929B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Barry Leiba Date: Thu, 29 Oct 2020 10:16:03 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-dots-server-discovery@ietf.org" , "dots-chairs@ietf.org" , "dots@ietf.org" , Valery Smyslov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 14:16:22 -0000 Perfect; thanks again, Med. Barry On Thu, Oct 29, 2020 at 9:30 AM wrote: > > Re-, > > Sure. Please check the update at: https://tinyurl.com/dots-discovery-iesg > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : Barry Leiba [mailto:barryleiba@computer.org] > > Envoy=C3=A9 : jeudi 29 octobre 2020 14:08 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > Cc : The IESG ; draft-ietf-dots-server- > > discovery@ietf.org; dots-chairs@ietf.org; dots@ietf.org; Valery > > Smyslov > > Objet : Re: Barry Leiba's No Objection on draft-ietf-dots-server- > > discovery-14: (with COMMENT) > > > > Hi, Med, and many thanks for making the changes and addressing my > > comments. > > > > > > Overall discussion question (but not at blocking DISCUSS level): > > > > Does it make sense for DOTS clients to proactively discover > > > > appropriate DOTS servers *before* a DDoS attack hits, to avoid > > the > > > > issue of discovery being blocked by the attack that the client > > is > > > > trying to report? Should this document discuss that? > > > > > > [Med] This is already covered in the text as the discovery is > > > triggered by new network attachments (which includes > > bootstrapping). > > > The discovery information is thus available independently of the > > attack conditions. > > > > Indeed, so the list at the end of Section 4 implies, and that ought > > to be enough. > > > > Still, may I ask for one more minor change, which I think makes it > > just a tad more explicit? In the lead-in to the list: > > > > OLD > > The discovery method is reiterated by a DOTS agent upon the > > following > > events: > > > > NEW > > The discovery method is performed upon attachment to a network, > > and is > > reiterated by a DOTS agent upon the following events: > > > > END > > > > > I understand the references in the terminology section may suggest > > > that knowledge is required. To avoid that, the terminology section > > is > > > updated to list the terms used in the document. > > > > I looked at the update, and that works for me; thanks! > > > > Barry > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > From nobody Thu Oct 29 12:14:52 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 994FF3A07A0; Thu, 29 Oct 2020 12:14:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk CC: kaduk@mit.edu, valery@smyslov.net, dots-chairs@ietf.org, dots@ietf.org, draft-ietf-dots-signal-call-home@ietf.org, Valery Smyslov Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160399889017.21404.7789392454090974016@ietfa.amsl.com> Date: Thu, 29 Oct 2020 12:14:50 -0700 Archived-At: Subject: [Dots] Last Call: (Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home) to Proposed Standard X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 19:14:51 -0000 The IESG has received a request from the DDoS Open Threat Signaling WG (dots) to consider the following document: - 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-11-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the DOTS signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client, and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- rfc8782-bis) Please update TBD/TBA statements with the assignments made by IANA to DOTS Signal Channel Call Home. Also, please update the "revision" date of the YANG module. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3825/ https://datatracker.ietf.org/ipr/3337/ https://datatracker.ietf.org/ipr/4405/ https://datatracker.ietf.org/ipr/3318/ The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-dots-rfc8782-bis: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification (None - IETF stream) From nobody Fri Oct 30 05:29: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 F31E43A0E3E for ; Fri, 30 Oct 2020 05:29:22 -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=unavailable 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 ZdPZbivC6c6z for ; Fri, 30 Oct 2020 05:29: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 BA9DB3A0FD0 for ; Fri, 30 Oct 2020 05:29: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 1kYTWd-0006FM-LS; Fri, 30 Oct 2020 12:28:59 +0000 From: To: "'Valery Smyslov'" , , , References: <0bf101d6ac30$19120f70$4b362e50$@smyslov.net> In-Reply-To: <0bf101d6ac30$19120f70$4b362e50$@smyslov.net> Date: Fri, 30 Oct 2020 12:28:42 -0000 Message-ID: <055c01d6aeb8$343c7080$9cb55180$@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: AQGJwhIeB7jlQFY3aMk0J9chc69o96pIp8sg Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-telemetry-13 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, 30 Oct 2020 12:29:23 -0000 Hi there, Issues found during Interop testing 30 Oct 2020. 1) ietf-dots-telemetry:telemetry is not in the CBOR mapping and needs to be added. 2) Clarity needed. We have A DOTS client uses a GET request to retrieve its vendor attack mapping details as maintained by the DOTS server (Figure 35). GET /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\ /ietf-dots-mapping:vendor-mapping?\ content=all HTTP/1.1 Host: example.com Accept: application/yang-data+json Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details If there has not been any POST/PUT vendor-mapping for dots-client=XX, what is the response for the GET? 4.04 or generic mappings that the server knows about? - my preference is for the HTTP 4.04 as there (currently) are no mapping details maintained for the dots-client= Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Valery > Smyslov > Sent: 27 October 2020 07:09 > To: dots@ietf.org > Cc: dots-chairs@ietf.org; draft-ietf-dots-telemetry@ietf.org > Subject: [Dots] WGLC for draft-ietf-dots-telemetry-13 > > Hi, > > this message starts a two-week working group last call for draft-ietf-dots- > telemetry-13, > which will end on Wednesday, November 11. Please, review the draft > carefully and > send your comments to the mailing list. > > Regards, > Frank & Valery. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Oct 30 05:56:02 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3E83A0E6E; Fri, 30 Oct 2020 05:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzBhliMcDM3R; Fri, 30 Oct 2020 05:56:00 -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 A242E3A0AAF; Fri, 30 Oct 2020 05:55:59 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4CN2Nt1ZFsz5vvr; Fri, 30 Oct 2020 13:55:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1604062558; bh=VaF9x4kWb8kZiJOeNw8W1rbAqvPTH5ur8KEXkEigi6s=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jYQmmnPtA7AOZWjSGIVG9UKnatNSlaeR1bNyELdi8wK7Q/JgumqbhCx5qAIpGULmn Jeh8i85t3tvjzBqnCk6ORqTSsTFM9ygjz2BPb9QV8WenxOwVmxypdMmhKUgSKgzNGC vYfhLYwaxCQr1Lg/hMdBKUy9wNL9DwCaQrOEVtE/uzVvOOHgsaUrbiWCNBE3puPmHJ PjRb390PuLORETInTv9LoWhLz3pN2gauloWxJGl1IzpwXcrLl8kJ+k43OG9t5Mkpuj BCt58nRhw1B8Z1egBgh3xkyNwJSJxyffe+7pRnCGqI1hH2mwTLXaqu18ap0NSy/FdO 4Q1ND+HreZzhg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4CN2Nt0dxFzDq8T; Fri, 30 Oct 2020 13:55:58 +0100 (CET) From: To: "supjps-ietf@jpshallow.com" , 'Valery Smyslov' , "dots@ietf.org" , "dots-chairs@ietf.org" , "draft-ietf-dots-telemetry@ietf.org" Thread-Topic: [Dots] WGLC for draft-ietf-dots-telemetry-13 Thread-Index: AQGJwhIeB7jlQFY3aMk0J9chc69o96pIp8sggAFHk6A= Date: Fri, 30 Oct 2020 12:55:57 +0000 Message-ID: <32669_1604062558_5F9C0D5E_32669_427_9_787AE7BB302AE849A7480A190F8B93303156B01D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <0bf101d6ac30$19120f70$4b362e50$@smyslov.net> <055c01d6aeb8$343c7080$9cb55180$@jpshallow.com> In-Reply-To: <055c01d6aeb8$343c7080$9cb55180$@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] WGLC for draft-ietf-dots-telemetry-13 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, 30 Oct 2020 12:56:02 -0000 Hi Jon, Thank you for sharing these comments. Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de supjps- > ietf@jpshallow.com > Envoy=E9=A0: vendredi 30 octobre 2020 13:29 > =C0=A0: 'Valery Smyslov' ; dots@ietf.org; dots- > chairs@ietf.org; draft-ietf-dots-telemetry@ietf.org > Objet=A0: Re: [Dots] WGLC for draft-ietf-dots-telemetry-13 >=20 > Hi there, >=20 > Issues found during Interop testing 30 Oct 2020. >=20 > 1) > ietf-dots-telemetry:telemetry is not in the CBOR mapping and needs > to be added. >=20 [Med] Indeed. This used to be 32916 in the implementation mapping table. Fixed in https://github.com/boucadair/draft-dots-telemetry/commit/f0ffd2bee= 65ccedf728f57b0769ee56eabb1e861. Thanks.=20 > 2) > Clarity needed. We have >=20 > A DOTS client uses a GET request to retrieve its vendor attack > mapping details as maintained by the DOTS server (Figure 35). >=20 > GET /restconf/data/ietf-dots-data-channel:dots-data\ > /dots-client=3Ddz6pHjaADkaFTbjr0JGBpw\ > /ietf-dots-mapping:vendor-mapping?\ > content=3Dall HTTP/1.1 > Host: example.com > Accept: application/yang-data+json >=20 > Figure 35: GET to Retrieve Installed Vendor Attack Mapping > Details >=20 > If there has not been any POST/PUT vendor-mapping for dots- > client=3DXX, what is the response for the GET? [Med] This one is covered by the base RESTCONF spec:=20 If a retrieval request for a data resource represents an instance that does not exist, then an error response containing a "404 Not Found" status-line MUST be returned by the server. This is why we don't specify a similar error in 8783 when no alias or filte= ring is matching a GET.=20 Please note that we don't discuss if the clients is not registered (and so = on) as these cases are already covered in 8783.=20 > 4.04 or generic mappings that the server knows about? > - my preference is for the HTTP 4.04 as there (currently) are no > mapping details maintained for the dots-client=3D >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Valery > Smyslov > > Sent: 27 October 2020 07:09 > > To: dots@ietf.org > > Cc: dots-chairs@ietf.org; draft-ietf-dots-telemetry@ietf.org > > Subject: [Dots] WGLC for draft-ietf-dots-telemetry-13 > > > > Hi, > > > > this message starts a two-week working group last call for > draft-ietf-dots- > > telemetry-13, > > which will end on Wednesday, November 11. Please, review the draft > > carefully and send your comments to the mailing list. > > > > Regards, > > Frank & Valery. > > > > _______________________________________________ > > 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Oct 30 06:15: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 CD8983A0E6F for ; Fri, 30 Oct 2020 06:15: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 m-9K6OlDzNfL for ; Fri, 30 Oct 2020 06:15:50 -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 D7C973A0E1B for ; Fri, 30 Oct 2020 06:15: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 1kYUFv-0006HN-2f; Fri, 30 Oct 2020 13:15:47 +0000 From: To: , "'Valery Smyslov'" , , , References: <0bf101d6ac30$19120f70$4b362e50$@smyslov.net> <055c01d6aeb8$343c7080$9cb55180$@jpshallow.com> <32669_1604062558_5F9C0D5E_32669_427_9_787AE7BB302AE849A7480A190F8B93303156B01D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <32669_1604062558_5F9C0D5E_32669_427_9_787AE7BB302AE849A7480A190F8B93303156B01D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 30 Oct 2020 13:15:30 -0000 Message-ID: <056901d6aebe$bd91da40$38b58ec0$@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: AQGJwhIeB7jlQFY3aMk0J9chc69o9wLRoRO7AZAnVmiqJuqQsA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC for draft-ietf-dots-telemetry-13 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, 30 Oct 2020 13:15:52 -0000 Hi Med, Thanks for the comments/update - all good for me. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 30 October 2020 12:56 > To: supjps-ietf@jpshallow.com; 'Valery Smyslov'; dots@ietf.org; dots- > chairs@ietf.org; draft-ietf-dots-telemetry@ietf.org > Subject: Re: [Dots] WGLC for draft-ietf-dots-telemetry-13 >=20 > Hi Jon, >=20 > Thank you for sharing these comments. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de supjps- > > ietf@jpshallow.com > > Envoy=E9=A0: vendredi 30 octobre 2020 13:29 > > =C0=A0: 'Valery Smyslov' ; dots@ietf.org; dots- > > chairs@ietf.org; draft-ietf-dots-telemetry@ietf.org > > Objet=A0: Re: [Dots] WGLC for draft-ietf-dots-telemetry-13 > > > > Hi there, > > > > Issues found during Interop testing 30 Oct 2020. > > > > 1) > > ietf-dots-telemetry:telemetry is not in the CBOR mapping and needs > > to be added. > > >=20 > [Med] Indeed. This used to be 32916 in the implementation mapping = table. >=20 > Fixed in https://github.com/boucadair/draft-dots- > telemetry/commit/f0ffd2bee65ccedf728f57b0769ee56eabb1e861. Thanks. >=20 > > 2) > > Clarity needed. We have > > > > A DOTS client uses a GET request to retrieve its vendor attack > > mapping details as maintained by the DOTS server (Figure 35). > > > > GET /restconf/data/ietf-dots-data-channel:dots-data\ > > /dots-client=3Ddz6pHjaADkaFTbjr0JGBpw\ > > /ietf-dots-mapping:vendor-mapping?\ > > content=3Dall HTTP/1.1 > > Host: example.com > > Accept: application/yang-data+json > > > > Figure 35: GET to Retrieve Installed Vendor Attack Mapping > > Details > > > > If there has not been any POST/PUT vendor-mapping for dots- > > client=3DXX, what is the response for the GET? >=20 > [Med] This one is covered by the base RESTCONF spec: >=20 > If a retrieval request for a data resource represents an instance > that does not exist, then an error response containing a "404 Not > Found" status-line MUST be returned by the server. >=20 > This is why we don't specify a similar error in 8783 when no alias or filtering > is matching a GET. >=20 > Please note that we don't discuss if the clients is not registered = (and so on) > as these cases are already covered in 8783. >=20 > > 4.04 or generic mappings that the server knows about? > > - my preference is for the HTTP 4.04 as there (currently) are no > > mapping details maintained for the dots-client=3D > > > > Regards > > > > Jon > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Valery > > Smyslov > > > Sent: 27 October 2020 07:09 > > > To: dots@ietf.org > > > Cc: dots-chairs@ietf.org; draft-ietf-dots-telemetry@ietf.org > > > Subject: [Dots] WGLC for draft-ietf-dots-telemetry-13 > > > > > > Hi, > > > > > > this message starts a two-week working group last call for > > draft-ietf-dots- > > > telemetry-13, > > > which will end on Wednesday, November 11. Please, review the draft > > > carefully and send your comments to the mailing list. > > > > > > Regards, > > > Frank & Valery. > > > > > > _______________________________________________ > > > 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 > ___________________________________________________________________ > ______________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou > falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Oct 30 16:30: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 5A4AF3A1443; Fri, 30 Oct 2020 16:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Schinazi via Datatracker To: Cc: last-call@ietf.org, draft-ietf-dots-signal-call-home.all@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160410062532.4190.5949270228585035968@ietfa.amsl.com> Reply-To: David Schinazi Date: Fri, 30 Oct 2020 16:30:25 -0700 Archived-At: Subject: [Dots] Genart last call review of draft-ietf-dots-signal-call-home-11 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 23:30:25 -0000 Reviewer: David Schinazi Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dots-signal-call-home-11 Reviewer: David Schinazi Review Date: 2020-10-30 IETF LC End Date: 2020-11-12 IESG Telechat date: Not scheduled for a telechat Summary: Thanks for a clear document, I didn't see any issues from a GenART perspective. Major issues: Minor issues: Nits/editorial comments: From nobody Fri Oct 30 22:47:35 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 7B2F23A0B04; Fri, 30 Oct 2020 22:47:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-dots-server-discovery@ietf.org, dots-chairs@ietf.org, dots@ietf.org, Valery Smyslov , valery@smyslov.net X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <160412323848.7479.1858151409881448369@ietfa.amsl.com> Date: Fri, 30 Oct 2020 22:47:18 -0700 Archived-At: Subject: [Dots] Martin Duke's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 05:47:19 -0000 Martin Duke has entered the following ballot position for draft-ietf-dots-server-discovery-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sec 5 ā€œ... this document allows for configuring names to DOTS clients ...ā€œ I think this means that the client receives server names, not that the clients have names themselves. But Iā€™m not sure.