From nobody Mon Jan 6 00:54: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 C33A8120073; Mon, 6 Jan 2020 00:54:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <157830084073.8016.12923818509935737003@ietfa.amsl.com> Date: Mon, 06 Jan 2020 00:54:00 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-41.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: Mon, 06 Jan 2020 08:54:01 -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 Specification Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-41.txt Pages : 108 Date : 2020-01-06 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. 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 Specification"; 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) Data Channel Specification (used to be I-D.ietf-dots-data- channel) Please update TBD/TBD1/TBD2 statements with the assignments made by IANA to DOTS Signal Channel Protocol. Also, please update the "revision" date of the YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-41 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-41 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-41 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 Jan 6 16:08: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 1F4BF120112; Mon, 6 Jan 2020 16:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a9LC7ph9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HEZYNjVR 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 oIsYoydm0Ysl; Mon, 6 Jan 2020 16:07:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5EF1200CE; Mon, 6 Jan 2020 16:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6503; q=dns/txt; s=iport; t=1578355679; x=1579565279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Grx7V0MyYQ/fCbUPbg/kHGAGdWpp//ukP9s/x/ayg0I=; b=a9LC7ph9n9oB6dHrc5SpwOr/tOFfZ0EKpdOa7N9ecyysaGep+51hSStB IjIUCSWFuCq2pq/4uS+JgLE+bygvxVnoIoWObpU+hTuho0D+SerNyY7XF UQYkuynM+BHUGx3cXFS2DdVfjgbNLByEJEDmnxh8q1IYpo+rYuvKV14LB A=; IronPort-PHdr: =?us-ascii?q?9a23=3Av+P9iRYpowyP8vAtsnqGVAX/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavydSUhBM1eVXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgCPyhNe/4oNJK1mHQEBAQkBEQU?= =?us-ascii?q?FAYFrBQELAYEkLyQsBWxYIAQLKoQJg0YDiwOCOpNQhGKCUgNUCQEBAQwBAS0?= =?us-ascii?q?CAQGEQAIXgVIkNwYOAgMNAQEEAQEBAgEFBG2FNwyFXwIBAxIRHQEBNwEPAgE?= =?us-ascii?q?IPwMCAgIwFBEBAQQBDQUigwABgXlNAy4BAqJbAoE4iGF1gTKCfgEBBYUCGII?= =?us-ascii?q?MCYE2AYwYGoFBP4E4DBSCTD6EMy2CeTKCLJA+hVeJY48lCoI2lhobgkaHfZA?= =?us-ascii?q?YjlOaWQIEAgQFAg4BAQWBaCMqgS5wFWUBgkFQGA2NEoNzilN0gSiNPwEB?= X-IronPort-AV: E=Sophos;i="5.69,404,1571702400"; d="scan'208,217";a="690430402" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 00:07:57 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 00707vQU023506 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 00:07:57 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 18:07:56 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 18:07:55 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 18:07:55 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ik9iSXIWfSkOBv27rrngUQ+7a5SJ2m9ZetRhsFsBBQhg8GK36Esj+dWpxmQgIDZTbB0oyTMVTulFTordAFR5I43ebDT2pBddrsXBepznUVNoaRvke3mNySh8lnguAljGuG1RX7CsXKeKfmUfSc3UcxnuuT1auA0RvX2vaqJsQb+FPNLzBfYT1GQltUrqsfm8F3yhJqSQ7vUZTucKVocq8SCi9wpSsphEsJiuUuvJCsq7TjWYQU3eqWIrp4maYJXMMQvKo2v7qFxsbwQ73q2ff/N5lLaCmjuDrO9IcC4IiTN6QvW4r7MhnxNJ7V47pjqjhJk3HHqrAm/6C8xzFkdaiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Grx7V0MyYQ/fCbUPbg/kHGAGdWpp//ukP9s/x/ayg0I=; b=iTZ1DzARToi9W14kkGvlpRHAyqEQjmR/5Svvn8INBIaxcsLn1ObVTbYCdLCKWAbA8GLFlOKxYwQouP9Jm3Tw4j1XiHfMF/6o1dda5H9aRGwDqI5jyjIBr00DAb/J81Qlo0B8Z1e3IbBh/0oPOD16rOvObQGUZJWEeh3ZVx2M1ceVofv34iPTgarE/P7Jbaaaru+ioVos5/Vw8RxBKKpY6xEfjCIhoQH7wD2erkIJgJ0DX3j2EDFj5kt2Twm4PIifQXRkJKfIrQS5rzVZjS18o9LIMrYmDx0Bgpt0v+5NwDdSf5R3w/h1HPLf+Pob+HRPoAeOwGCxGumoMOeQFP2jag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Grx7V0MyYQ/fCbUPbg/kHGAGdWpp//ukP9s/x/ayg0I=; b=HEZYNjVRwWsR5ryaUZRZnHooknCq7BXU65aH2k/CrhlmPmqsj+ssP3azlCwA7xc02eKFHWc8zmRT8HyMwPsNpkOz/doVRfk19sShse1j5LMqeYrhu/yOjP/bTV9QWiHb7VM8B2ea5iKIgtNQwgFc/47yNEpy7WYSPEyM1L7pjWY= Received: from BYAPR11MB3768.namprd11.prod.outlook.com (20.178.238.20) by BYAPR11MB3478.namprd11.prod.outlook.com (20.177.184.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Tue, 7 Jan 2020 00:07:54 +0000 Received: from BYAPR11MB3768.namprd11.prod.outlook.com ([fe80::2593:53c4:9536:83c1]) by BYAPR11MB3768.namprd11.prod.outlook.com ([fe80::2593:53c4:9536:83c1%7]) with mapi id 15.20.2602.016; Tue, 7 Jan 2020 00:07:54 +0000 From: "Prashanth Patil (praspati)" To: Valery Smyslov , "draft-ietf-dots-server-discovery@ietf.org" CC: "dots@ietf.org" , "dots-chairs@ietf.org" Thread-Topic: IPR disclouser for draft-ietf-dots-server-discovery-06 Thread-Index: AdW5YorMVTfIeSgCSOe9CcQ65F1hqwLSOWAA Date: Tue, 7 Jan 2020 00:07:53 +0000 Message-ID: <2B8E4C9C-3A9E-4260-85FB-9DAD60FD24EF@cisco.com> References: <01e401d5b962$cf0284c0$6d078e40$@smyslov.net> In-Reply-To: <01e401d5b962$cf0284c0$6d078e40$@smyslov.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=praspati@cisco.com; x-originating-ip: [2001:420:c0c8:1004::246] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3d7f7b8-8bd7-4ac0-1e08-08d79305a485 x-ms-traffictypediagnostic: BYAPR11MB3478: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39860400002)(189003)(199004)(66946007)(53546011)(36756003)(81166006)(81156014)(6506007)(8936002)(8676002)(86362001)(9326002)(66446008)(66556008)(66476007)(76116006)(71200400001)(64756008)(186003)(4326008)(5660300002)(2906002)(4744005)(316002)(2616005)(6486002)(6512007)(33656002)(54906003)(478600001)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3478; H:BYAPR11MB3768.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OB9/Zl//S2PPRvPoPltdNurapn77XOOoQUf6nkYZeW2NFZCc4y/CkpVW/g/UdhDgy3P9WgQKxK9cmAZS8Bqrf9gdIqC/Y+1F8XtGeBxhQib5u+m/dNk8ij02Wuz1c0mSSQBsIV7WOwmOclKPHpN5LLVu5UddhKyb18Mft4WqsfEuMdp5mJidAtQ+XKBjcwWNNwbxLT6NdJJY3+jCUXx1X6/jjKpO4G5Ex+Me08b6B2PMryPj/xAoNuivDOBUMwwIL0cWV0B4M+/wEdcxgI6CwpnQjsaH8VhuOBDG+0L0yyccyYrB8opaK0nzrCr/RpJv1jmWYR5j2ZJbxisF0FZgaNFbk7OgsVUzpoxC54bUxQiUSYmkdsFqr8POPMoEpG+XTA2Y8NGJFIpWAHXpEwZpAhjFMWym9lDU7qDz7Y1Xrv4EQQA7esBgz+AZsLyVIIsi x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_2B8E4C9C3A9E426085FB9DAD60FD24EFciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b3d7f7b8-8bd7-4ac0-1e08-08d79305a485 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 00:07:53.7253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TMpAp/DTT2uniGY4Mzim0XPf16AiaLA5QU7TAjGmYNzCcJfkMbV28h5CohzhLCgGHshH+fitAQm8H1FlM/CdCw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3478 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Dots] IPR disclouser for draft-ietf-dots-server-discovery-06 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 00:08:01 -0000 --_000_2B8E4C9C3A9E426085FB9DAD60FD24EFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmFsZXJ5LA0KQXBvbG9naWVzIGZvciB0aGUgZGVsYXkgaW4gcmVzcG9uc2UuIEkgZG9uJ3Qg aGF2ZSBub3IgSSdtIGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0KDQpU aGFua3MsDQpQcmFzaGFudGgNCg0KT24gMTIvMjIvMTksIDExOjMwIFBNLCAiVmFsZXJ5IFNteXNs b3YiIDx2YWxlcnlAc215c2xvdi5uZXQ8bWFpbHRvOnZhbGVyeUBzbXlzbG92Lm5ldD4+IHdyb3Rl Og0KDQpIaSwNCg0Kd2hpbGUgcHJlcGFyaW5nIHNoZXBoZXJkIHdyaXRlLXVwIGZvciBkcmFmdC1p ZXRmLWRvdHMtc2VydmVyLWRpc2NvdmVyeS0wNg0KSSBzaG91bGQgY29sbGVjdCBjb25maXJtYXRp b25zIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yIHRoYXQNCmFueSBhbmQgYWxsIGFw cHJvcHJpYXRlIElQUiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZQ0K d2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVl biBmaWxlZC4NCg0KUGxlYXNlIGNvbmZpcm0gdGhpcyBieSByZXBseWluZyB0byB0aGlzIG1lc3Nh Z2UuDQoNClJlZ2FyZHMsDQpWYWxlcnkuDQoNCg0KDQo= --_000_2B8E4C9C3A9E426085FB9DAD60FD24EFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <494152B13439594AA545CC74B8B60A82@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFZhbGVyeSwgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBpbiByZXNwb25z ZS4gPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCkkgZG9uJ3QgaGF2ZSBub3IgSSdtIGF3YXJl IG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJh c2hhbnRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPk9uIDEyLzIyLzE5LCAxMTozMCBQTSwgJnF1b3Q7VmFsZXJ5IFNteXNsb3Ym cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2YWxlcnlAc215c2xvdi5uZXQiPnZhbGVyeUBzbXlz bG92Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+d2hpbGUgcHJlcGFyaW5nIHNoZXBoZXJkIHdyaXRlLXVwIGZvciBkcmFm dC1pZXRmLWRvdHMtc2VydmVyLWRpc2NvdmVyeS0wNg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBz aG91bGQgY29sbGVjdCBjb25maXJtYXRpb25zIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1 dG9yIHRoYXQNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFueSBhbmQgYWxsIGFwcHJvcHJpYXRlIElQ UiBkaXNjbG9zdXJlcyByZXF1aXJlZCBmb3IgZnVsbCBjb25mb3JtYW5jZQ0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+d2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OSBoYXZlIGFs cmVhZHkgYmVlbiBmaWxlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5QbGVhc2UgY29uZmlybSB0aGlzIGJ5IHJlcGx5aW5nIHRvIHRoaXMgbWVzc2FnZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlZhbGVyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2B8E4C9C3A9E426085FB9DAD60FD24EFciscocom_-- From nobody Tue Jan 7 06:32:38 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 E67D1120834; Tue, 7 Jan 2020 06:32:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <157840754887.20859.1382575407155457150@ietfa.amsl.com> Date: Tue, 07 Jan 2020 06:32:28 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 14:32:33 -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-07.txt Pages : 23 Date : 2020-01-07 Abstract: It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure DOTS clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 7 07:28:49 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 87EAA120219 for ; Tue, 7 Jan 2020 07:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zWZ3w47pbWnu for ; Tue, 7 Jan 2020 07:28:45 -0800 (PST) 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 D3AFF1201EA for ; Tue, 7 Jan 2020 07:28:44 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 47sbrC0Cdgz8tJ8 for ; Tue, 7 Jan 2020 16:28:43 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 47sbrB6XYyzCqkM for ; Tue, 7 Jan 2020 16:28:42 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Tue, 7 Jan 2020 16:28:42 +0100 From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-server-discovery-07.txt Thread-Index: AQHVxWdUqWagKn9gNkS/olksDqcqyKffUz6Q Date: Tue, 7 Jan 2020 15:28:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313F4647@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157840754887.20859.1382575407155457150@ietfa.amsl.com> In-Reply-To: <157840754887.20859.1382575407155457150@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-server-discovery-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 15:28:48 -0000 Hi all,=20 The new version fixes some IANA considerations suggested by Valery.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mardi 7 janvier 2020 15:32 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-server-discovery-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed-Denial-of-Service Open Threat > Signaling (DOTS) Agent Discovery > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Filename : draft-ietf-dots-server-discovery-07.txt > Pages : 23 > Date : 2020-01-07 >=20 > Abstract: > It may not be possible for a network to determine the cause for an > attack, but instead just realize that some resources seem to be under > attack. To fill that gap, Distributed-Denial-of-Service Open Threat > Signaling (DOTS) allows a network to inform a DOTS server that it is > under a potential attack so that appropriate mitigation actions are > undertaken. >=20 > This document specifies mechanisms to configure DOTS clients with > their DOTS servers. The discovery procedure also covers the DOTS > Signal Channel Call Home. >=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-07 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery- > 07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-server-discovery-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Jan 7 09:10: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 98E7C120052; Tue, 7 Jan 2020 09:10:08 -0800 (PST) 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: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-dots-signal-channel@ietf.org, The IESG , dots@ietf.org, frank.xialiang@huawei.com, kaduk@mit.edu, dots-chairs@ietf.org, rfc-editor@rfc-editor.org, Liang Xia Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157841700862.20985.14116369579091975153.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 09:10:08 -0800 Archived-At: Subject: [Dots] Protocol Action: 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification' to Proposed Standard (draft-ietf-dots-signal-channel-41.txt) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 17:10:09 -0000 The IESG has approved the following document: - 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification' (draft-ietf-dots-signal-channel-41.txt) as Proposed Standard This document is the product of the DDoS Open Threat Signaling Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ Technical Summary This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. This is a companion document to the DOTS data channel specification. Working Group Summary This draft has been extensively reviewed and discussed within the working group by mailing list and github. The latest document is well written and reaches a broad consensus in WG. Document Quality The co-authors are from some of the leading vendors and operators in DDoS protection industry with extensive experience with the related technologies and implementations; they are also the core authors of the DOTS requirements WG drafts, which guarantees consistency between the core DOTS protocol documents. Until now, there are three demo implementations for it (open source go-dots from NTT and two proprietary demos from NCC and Huawei), and several rounds of interop tests during IETF hackathon activities. All the technical issues identified by these demos and the finished tests have been addressed and reflected into the latest draft, which are very helpful for the completeness and quality improvement of the draft. IANA port number expert review is ongoing; the expert is seeking additional justification that a dedicated port is needed, which has been provided by the document authors. Personnel The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk. From nobody Tue Jan 7 09:17:37 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791FD12012A; Tue, 7 Jan 2020 09:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wj2uOVn4NYA8; Tue, 7 Jan 2020 09:17:31 -0800 (PST) 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 53386120125; Tue, 7 Jan 2020 09:17:31 -0800 (PST) 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 007HHRTg010315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jan 2020 12:17:29 -0500 Date: Tue, 7 Jan 2020 09:17:27 -0800 From: Benjamin Kaduk To: draft-ietf-dots-signal-channel@ietf.org Cc: dots@ietf.org Message-ID: <20200107171727.GW57294@kduck.mit.edu> References: <157841700862.20985.14116369579091975153.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157841700862.20985.14116369579091975153.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Dots] Protocol Action: 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification' to Proposed Standard (draft-ietf-dots-signal-channel-41.txt) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 17:17:34 -0000 Thank you for all your hard work to get this document approved; I'm happy with where we ended up (even if I'm not happy that it took so long)! -Ben On Tue, Jan 07, 2020 at 09:10:08AM -0800, The IESG wrote: > The IESG has approved the following document: > - 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal > Channel Specification' > (draft-ietf-dots-signal-channel-41.txt) as Proposed Standard > > This document is the product of the DDoS Open Threat Signaling Working Group. > > The IESG contact persons are Benjamin Kaduk and Roman Danyliw. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > > Technical Summary > > This document specifies the DOTS signal channel, a protocol for signaling > the need for protection against Distributed Denial-of-Service (DDoS) > attacks to a server capable of enabling network traffic mitigation on > behalf of the requesting client. > > This is a companion document to the DOTS data channel specification. > > Working Group Summary > > This draft has been extensively reviewed and discussed within the > working group by mailing list and github. The latest document is > well written and reaches a broad consensus in WG. > > Document Quality > > The co-authors are from some of the leading vendors and operators in > DDoS protection industry with extensive experience with the related > technologies and implementations; they are also the core authors of > the DOTS requirements WG drafts, which guarantees consistency between > the core DOTS protocol documents. Until now, there are three demo > implementations for it (open source go-dots from NTT and two > proprietary demos from NCC and Huawei), and several rounds of interop > tests during IETF hackathon activities. All the technical issues > identified by these demos and the finished tests have been addressed > and reflected into the latest draft, which are very helpful for the > completeness and quality improvement of the draft. > > IANA port number expert review is ongoing; the expert is seeking > additional justification that a dedicated port is needed, which has > been provided by the document authors. > > Personnel > > The document shepherd is Liang Xia. The responsible Area Director is > Benjamin Kaduk. From nobody Tue Jan 7 22:52:51 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79E120043; Tue, 7 Jan 2020 22:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TjVqSrBuLduM; Tue, 7 Jan 2020 22:52:47 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0771B120041; Tue, 7 Jan 2020 22:52:47 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9ED51A01435E914A850E; Wed, 8 Jan 2020 06:52:42 +0000 (GMT) Received: from lhreml733-chm.china.huawei.com (10.201.108.84) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 8 Jan 2020 06:52:42 +0000 Received: from lhreml733-chm.china.huawei.com (10.201.108.84) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 8 Jan 2020 06:52:42 +0000 Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 8 Jan 2020 06:52:41 +0000 Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.184]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0439.000; Wed, 8 Jan 2020 14:52:36 +0800 From: "Xialiang (Frank, Network Standard & Patent Dept)" To: Benjamin Kaduk , "draft-ietf-dots-signal-channel@ietf.org" CC: "dots@ietf.org" Thread-Topic: [Dots] Protocol Action: 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification' to Proposed Standard (draft-ietf-dots-signal-channel-41.txt) Thread-Index: AQHVxX1UpD/EVMW9mEGremfG8zFN+6fe65SAgAFpXuA= Date: Wed, 8 Jan 2020 06:52:36 +0000 Message-ID: References: <157841700862.20985.14116369579091975153.idtracker@ietfa.amsl.com> <20200107171727.GW57294@kduck.mit.edu> In-Reply-To: <20200107171727.GW57294@kduck.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.46] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] =?gb2312?b?tPC4tDogIFByb3RvY29sIEFjdGlvbjogJ0Rpc3RyaWJ1?= =?gb2312?b?dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAo?= =?gb2312?b?RE9UUykgU2lnbmFsIENoYW5uZWwgU3BlY2lmaWNhdGlvbicgdG8gUHJvcG9z?= =?gb2312?b?ZWQgU3RhbmRhcmQgKGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC00?= =?gb2312?b?MS50eHQp?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 06:52:49 -0000 R29vZCBuZXdzLCB0aGFua3MgYWxsIGZvciB0aGUgaGFyZCB3b3JrIHRvIGdldCB0aGlzIGRvbmUu DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIEJlbmphbWluIEthZHVrDQq3osvNyrG85DogMjAyMMTqMdTCOMjVIDE6 MTcNCsrVvP7IyzogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsQGlldGYub3JnDQqzrcvN OiBkb3RzQGlldGYub3JnDQrW98ziOiBSZTogW0RvdHNdIFByb3RvY29sIEFjdGlvbjogJ0Rpc3Ry aWJ1dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgU2ln bmFsIENoYW5uZWwgU3BlY2lmaWNhdGlvbicgdG8gUHJvcG9zZWQgU3RhbmRhcmQgKGRyYWZ0LWll dGYtZG90cy1zaWduYWwtY2hhbm5lbC00MS50eHQpDQoNClRoYW5rIHlvdSBmb3IgYWxsIHlvdXIg aGFyZCB3b3JrIHRvIGdldCB0aGlzIGRvY3VtZW50IGFwcHJvdmVkOyBJJ20gaGFwcHkgd2l0aCB3 aGVyZSB3ZSBlbmRlZCB1cCAoZXZlbiBpZiBJJ20gbm90IGhhcHB5IHRoYXQgaXQgdG9vayBzbyBs b25nKSENCg0KLUJlbg0KDQpPbiBUdWUsIEphbiAwNywgMjAyMCBhdCAwOToxMDowOEFNIC0wODAw LCBUaGUgSUVTRyB3cm90ZToNCj4gVGhlIElFU0cgaGFzIGFwcHJvdmVkIHRoZSBmb2xsb3dpbmcg ZG9jdW1lbnQ6DQo+IC0gJ0Rpc3RyaWJ1dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0 IFNpZ25hbGluZyAoRE9UUykgU2lnbmFsDQo+ICAgIENoYW5uZWwgU3BlY2lmaWNhdGlvbicNCj4g ICAoZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTQxLnR4dCkgYXMgUHJvcG9zZWQgU3Rh bmRhcmQNCj4gDQo+IFRoaXMgZG9jdW1lbnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIEREb1MgT3Bl biBUaHJlYXQgU2lnbmFsaW5nIFdvcmtpbmcgR3JvdXAuDQo+IA0KPiBUaGUgSUVTRyBjb250YWN0 IHBlcnNvbnMgYXJlIEJlbmphbWluIEthZHVrIGFuZCBSb21hbiBEYW55bGl3Lg0KPiANCj4gQSBV Ukwgb2YgdGhpcyBJbnRlcm5ldCBEcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLw0KPiANCj4gDQo+IA0KPiAN Cj4gVGVjaG5pY2FsIFN1bW1hcnkNCj4gDQo+ICAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0 aGUgRE9UUyBzaWduYWwgY2hhbm5lbCwgYSBwcm90b2NvbCBmb3Igc2lnbmFsaW5nDQo+ICAgICB0 aGUgbmVlZCBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IERpc3RyaWJ1dGVkIERlbmlhbC1vZi1TZXJ2 aWNlIChERG9TKQ0KPiAgICAgYXR0YWNrcyB0byBhIHNlcnZlciBjYXBhYmxlIG9mIGVuYWJsaW5n IG5ldHdvcmsgdHJhZmZpYyBtaXRpZ2F0aW9uIG9uDQo+ICAgICBiZWhhbGYgb2YgdGhlIHJlcXVl c3RpbmcgY2xpZW50Lg0KPiAgICAgDQo+ICAgICBUaGlzIGlzIGEgY29tcGFuaW9uIGRvY3VtZW50 IHRvIHRoZSBET1RTIGRhdGEgY2hhbm5lbCBzcGVjaWZpY2F0aW9uLg0KPiANCj4gV29ya2luZyBH cm91cCBTdW1tYXJ5DQo+ICAgIA0KPiAgICAgVGhpcyBkcmFmdCBoYXMgYmVlbiBleHRlbnNpdmVs eSByZXZpZXdlZCBhbmQgZGlzY3Vzc2VkIHdpdGhpbiB0aGUNCj4gICAgIHdvcmtpbmcgZ3JvdXAg YnkgbWFpbGluZyBsaXN0IGFuZCBnaXRodWIuICBUaGUgbGF0ZXN0IGRvY3VtZW50IGlzDQo+ICAg ICB3ZWxsIHdyaXR0ZW4gYW5kIHJlYWNoZXMgYSBicm9hZCBjb25zZW5zdXMgaW4gV0cuDQo+IA0K PiBEb2N1bWVudCBRdWFsaXR5DQo+IA0KPiAgICBUaGUgY28tYXV0aG9ycyBhcmUgZnJvbSBzb21l IG9mIHRoZSBsZWFkaW5nIHZlbmRvcnMgYW5kIG9wZXJhdG9ycyBpbg0KPiAgICBERG9TIHByb3Rl Y3Rpb24gaW5kdXN0cnkgd2l0aCBleHRlbnNpdmUgZXhwZXJpZW5jZSB3aXRoIHRoZSByZWxhdGVk DQo+ICAgIHRlY2hub2xvZ2llcyBhbmQgaW1wbGVtZW50YXRpb25zOyB0aGV5IGFyZSBhbHNvIHRo ZSBjb3JlIGF1dGhvcnMgb2YNCj4gICAgdGhlIERPVFMgcmVxdWlyZW1lbnRzIFdHIGRyYWZ0cywg d2hpY2ggZ3VhcmFudGVlcyBjb25zaXN0ZW5jeSBiZXR3ZWVuDQo+ICAgIHRoZSBjb3JlIERPVFMg cHJvdG9jb2wgZG9jdW1lbnRzLiAgVW50aWwgbm93LCB0aGVyZSBhcmUgdGhyZWUgZGVtbw0KPiAg ICBpbXBsZW1lbnRhdGlvbnMgZm9yIGl0IChvcGVuIHNvdXJjZSBnby1kb3RzIGZyb20gTlRUIGFu ZCB0d28NCj4gICAgcHJvcHJpZXRhcnkgZGVtb3MgZnJvbSBOQ0MgYW5kIEh1YXdlaSksIGFuZCBz ZXZlcmFsIHJvdW5kcyBvZiBpbnRlcm9wDQo+ICAgIHRlc3RzIGR1cmluZyBJRVRGIGhhY2thdGhv biBhY3Rpdml0aWVzLiBBbGwgdGhlIHRlY2huaWNhbCBpc3N1ZXMNCj4gICAgaWRlbnRpZmllZCBi eSB0aGVzZSBkZW1vcyBhbmQgdGhlIGZpbmlzaGVkIHRlc3RzIGhhdmUgYmVlbiBhZGRyZXNzZWQN Cj4gICAgYW5kIHJlZmxlY3RlZCBpbnRvIHRoZSBsYXRlc3QgZHJhZnQsIHdoaWNoIGFyZSB2ZXJ5 IGhlbHBmdWwgZm9yIHRoZQ0KPiAgICBjb21wbGV0ZW5lc3MgYW5kIHF1YWxpdHkgaW1wcm92ZW1l bnQgb2YgdGhlIGRyYWZ0Lg0KPiANCj4gICAgSUFOQSBwb3J0IG51bWJlciBleHBlcnQgcmV2aWV3 IGlzIG9uZ29pbmc7IHRoZSBleHBlcnQgaXMgc2Vla2luZw0KPiAgICBhZGRpdGlvbmFsIGp1c3Rp ZmljYXRpb24gdGhhdCBhIGRlZGljYXRlZCBwb3J0IGlzIG5lZWRlZCwgd2hpY2ggaGFzDQo+ICAg IGJlZW4gcHJvdmlkZWQgYnkgdGhlIGRvY3VtZW50IGF1dGhvcnMuDQo+IA0KPiBQZXJzb25uZWwN Cj4gDQo+ICAgICBUaGUgZG9jdW1lbnQgc2hlcGhlcmQgaXMgTGlhbmcgWGlhLiBUaGUgcmVzcG9u c2libGUgQXJlYSBEaXJlY3RvciBpcw0KPiAgICAgQmVuamFtaW4gS2FkdWsuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlz dA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k b3RzDQo= From nobody Tue Jan 7 23:39: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 9B272120105 for ; Tue, 7 Jan 2020 23:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFq2O_qAS0QL for ; Tue, 7 Jan 2020 23:39:12 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBD312007C for ; Tue, 7 Jan 2020 23:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578469150; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Rhgt2xWF5EO7CxIlm9TcXsVr/ltCZnvwgdw+imB6p7s=; b=CMcJMxLMqtrqSJyCCHUNyePlhZMOlg2NnVb2gMN4M5eANhnYd+7qpmuoyUlS8qj3PZy/y8 6ELnh8tWdtSGM7I7PXcezQSl5lU4BpQylb1JLYCE/Tc1rh9giBw5usxSzWpAA/QWAIyNMJ Wr2a66WeOVvSF33lgy1etkjg00yozr8= Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2107.outbound.protection.outlook.com [104.47.58.107]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-69-PnKvOeHpODG_44ll5lwFRw-1; Wed, 08 Jan 2020 02:39:06 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1317.namprd16.prod.outlook.com (10.172.116.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 8 Jan 2020 07:39:02 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea%6]) with mapi id 15.20.2602.016; Wed, 8 Jan 2020 07:39:02 +0000 From: "Konda, Tirumaleswar Reddy" To: "Xialiang (Frank, Network Standard & Patent Dept)" , Benjamin Kaduk , "draft-ietf-dots-signal-channel@ietf.org" CC: "dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIOetlOWkjTogIFByb3RvY29sIEFjdGlvbjogJ0Rpc3RyaWJ1dGVk?= =?utf-8?B?IERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9U?= =?utf-8?B?UykgU2lnbmFsIENoYW5uZWwgU3BlY2lmaWNhdGlvbicgdG8gUHJvcG9zZWQg?= =?utf-8?B?U3RhbmRhcmQgKGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC00MS50?= =?utf-8?Q?xt)?= Thread-Index: AQHVxfBEJd+OwZDNZE6eh3aTU1MhHafgYLcw Date: Wed, 8 Jan 2020 07:39:02 +0000 Message-ID: References: <157841700862.20985.14116369579091975153.idtracker@ietfa.amsl.com> <20200107171727.GW57294@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 184e8660-df64-4769-7d67-08d7940dd535 x-ms-traffictypediagnostic: CY4PR1601MB1317: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(396003)(376002)(136003)(366004)(32952001)(13464003)(189003)(199004)(86362001)(6506007)(53546011)(7696005)(52536014)(5660300002)(64756008)(66476007)(186003)(66556008)(66446008)(66946007)(26005)(76116006)(71200400001)(2906002)(224303003)(9686003)(316002)(55016002)(110136005)(81166006)(81156014)(66574012)(966005)(478600001)(4326008)(33656002)(8936002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1317; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8jdYI6+LQf/4KLSoyYrMDasyXvNfoSWyKVArmvDYrgSmq8xEPxrqKkKpTXtXIwOQJ/zQlEAz+77igOblGEbOHxcpIechcC2c/psdcPAQzv/Yk8OgcH7rmEZSST1ajrsDgn8JY/yk+Gt7evZz6RmYUBRStYdc6L7Ld6kj5gQvJwELIRrjNXMKE39KOJFPhnBIcSvALE4ui+inuapFVPegDCwMMP/U2wFGUV9dg9ODitSIGd2w32wv/t5Wb/ZcH44TMqOLkp2b04l8myNw/gKMffOu0mjSE3seun91qgvR2wnZjgzmOHXxuQUUZQNRVa1fPDJ/E7BOlnsdvV5/MWMtgbb+Dw7gWC9wmYCbds4RE2bMBP8zGX5u1JDgE4EVdjxMO1XtKIpmsBzihpgF1Yqys5aImbeMTDw8w7WrhLpTzCU8p15Im+T/5aZOAIMIW1719Adio3p4cpqUYNveDky8vDFRTr6R5HJIQv0PbDR73onVFQYI+/GiPLHG626ALmgu0+Nm2GfgrL+/AHxppRTsa+F1QAlj4LwSxtP8P+oVhh+ZXmilF1aa+6eBeVqUbiLRz7OmuhuAlTBmyBhGG6zUFA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 184e8660-df64-4769-7d67-08d7940dd535 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 07:39:02.7563 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QJb9ckcmxrytZX0mHqcas1aINFhulZAgl8U/TA0gxJ0WUVls2EEbTGJZZ1Pdb0Y6sbx2yhPQLQGVFJdnRQ+doK9utON5J4J2Z5VbtrgcTRnHiHjoRKrZ1VRxcrhxeZw8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1317 X-MC-Unique: PnKvOeHpODG_44ll5lwFRw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Dots] =?utf-8?b?562U5aSNOiAgUHJvdG9jb2wgQWN0aW9uOiAnRGlzdHJp?= =?utf-8?q?buted_Denial-of-Service_Open_Threat_Signaling_=28DOTS=29_Signal?= =?utf-8?q?_Channel_Specification=27_to_Proposed_Standard_=28draft-ietf-do?= =?utf-8?q?ts-signal-channel-41=2Etxt=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 07:39:15 -0000 R2xhZCB0byBzZWUgdGhlIGRvY3VtZW50IHByb2dyZXNzZWQgYW5kIGFsbCB0aGUgZWZmb3J0IGZy b20gdGhlIFdHIHBhaWQgb2ZmLiANCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBYaWFsaWFuZyAoRnJhbmssIE5ldHdvcmsNCj4gU3RhbmRhcmQgJiBQYXRlbnQgRGVw dCkNCj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDgsIDIwMjAgMTI6MjMgUE0NCj4gVG86IEJl bmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PjsgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC0NCj4g Y2hhbm5lbEBpZXRmLm9yZw0KPiBDYzogZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbRG90c10g 562U5aSNOiBQcm90b2NvbCBBY3Rpb246ICdEaXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBP cGVuDQo+IFRocmVhdCBTaWduYWxpbmcgKERPVFMpIFNpZ25hbCBDaGFubmVsIFNwZWNpZmljYXRp b24nIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IChkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5u ZWwtNDEudHh0KQ0KPiANCj4gQ0FVVElPTjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBjbGljayBs aW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UNCj4gcmVjb2duaXplIHRoZSBzZW5k ZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEdvb2QgbmV3cywgdGhhbmtz IGFsbCBmb3IgdGhlIGhhcmQgd29yayB0byBnZXQgdGhpcyBkb25lLg0KPiANCj4gLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqCBCZW5qYW1pbiBLYWR1aw0KPiDlj5HpgIHml7bpl7Q6IDIwMjDlubQx5pyI OOaXpSAxOjE3DQo+IOaUtuS7tuS6ujogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsQGll dGYub3JnDQo+IOaKhOmAgTogZG90c0BpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbRG90c10gUHJv dG9jb2wgQWN0aW9uOiAnRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQN Cj4gU2lnbmFsaW5nIChET1RTKSBTaWduYWwgQ2hhbm5lbCBTcGVjaWZpY2F0aW9uJyB0byBQcm9w b3NlZCBTdGFuZGFyZCAoZHJhZnQtDQo+IGlldGYtZG90cy1zaWduYWwtY2hhbm5lbC00MS50eHQp DQo+IA0KPiBUaGFuayB5b3UgZm9yIGFsbCB5b3VyIGhhcmQgd29yayB0byBnZXQgdGhpcyBkb2N1 bWVudCBhcHByb3ZlZDsgSSdtIGhhcHB5DQo+IHdpdGggd2hlcmUgd2UgZW5kZWQgdXAgKGV2ZW4g aWYgSSdtIG5vdCBoYXBweSB0aGF0IGl0IHRvb2sgc28gbG9uZykhDQo+IA0KPiAtQmVuDQo+IA0K PiBPbiBUdWUsIEphbiAwNywgMjAyMCBhdCAwOToxMDowOEFNIC0wODAwLCBUaGUgSUVTRyB3cm90 ZToNCj4gPiBUaGUgSUVTRyBoYXMgYXBwcm92ZWQgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCj4g PiAtICdEaXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcg KERPVFMpIFNpZ25hbA0KPiA+ICAgIENoYW5uZWwgU3BlY2lmaWNhdGlvbicNCj4gPiAgIChkcmFm dC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtNDEudHh0KSBhcyBQcm9wb3NlZCBTdGFuZGFyZA0K PiA+DQo+ID4gVGhpcyBkb2N1bWVudCBpcyB0aGUgcHJvZHVjdCBvZiB0aGUgRERvUyBPcGVuIFRo cmVhdCBTaWduYWxpbmcgV29ya2luZw0KPiBHcm91cC4NCj4gPg0KPiA+IFRoZSBJRVNHIGNvbnRh Y3QgcGVyc29ucyBhcmUgQmVuamFtaW4gS2FkdWsgYW5kIFJvbWFuIERhbnlsaXcuDQo+ID4NCj4g PiBBIFVSTCBvZiB0aGlzIEludGVybmV0IERyYWZ0IGlzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC8NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IFRlY2huaWNhbCBTdW1tYXJ5DQo+ID4NCj4gPiAgICAgVGhpcyBkb2N1 bWVudCBzcGVjaWZpZXMgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwsIGEgcHJvdG9jb2wgZm9yIHNp Z25hbGluZw0KPiA+ICAgICB0aGUgbmVlZCBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IERpc3RyaWJ1 dGVkIERlbmlhbC1vZi1TZXJ2aWNlIChERG9TKQ0KPiA+ICAgICBhdHRhY2tzIHRvIGEgc2VydmVy IGNhcGFibGUgb2YgZW5hYmxpbmcgbmV0d29yayB0cmFmZmljIG1pdGlnYXRpb24gb24NCj4gPiAg ICAgYmVoYWxmIG9mIHRoZSByZXF1ZXN0aW5nIGNsaWVudC4NCj4gPg0KPiA+ICAgICBUaGlzIGlz IGEgY29tcGFuaW9uIGRvY3VtZW50IHRvIHRoZSBET1RTIGRhdGEgY2hhbm5lbCBzcGVjaWZpY2F0 aW9uLg0KPiA+DQo+ID4gV29ya2luZyBHcm91cCBTdW1tYXJ5DQo+ID4NCj4gPiAgICAgVGhpcyBk cmFmdCBoYXMgYmVlbiBleHRlbnNpdmVseSByZXZpZXdlZCBhbmQgZGlzY3Vzc2VkIHdpdGhpbiB0 aGUNCj4gPiAgICAgd29ya2luZyBncm91cCBieSBtYWlsaW5nIGxpc3QgYW5kIGdpdGh1Yi4gIFRo ZSBsYXRlc3QgZG9jdW1lbnQgaXMNCj4gPiAgICAgd2VsbCB3cml0dGVuIGFuZCByZWFjaGVzIGEg YnJvYWQgY29uc2Vuc3VzIGluIFdHLg0KPiA+DQo+ID4gRG9jdW1lbnQgUXVhbGl0eQ0KPiA+DQo+ ID4gICAgVGhlIGNvLWF1dGhvcnMgYXJlIGZyb20gc29tZSBvZiB0aGUgbGVhZGluZyB2ZW5kb3Jz IGFuZCBvcGVyYXRvcnMgaW4NCj4gPiAgICBERG9TIHByb3RlY3Rpb24gaW5kdXN0cnkgd2l0aCBl eHRlbnNpdmUgZXhwZXJpZW5jZSB3aXRoIHRoZSByZWxhdGVkDQo+ID4gICAgdGVjaG5vbG9naWVz IGFuZCBpbXBsZW1lbnRhdGlvbnM7IHRoZXkgYXJlIGFsc28gdGhlIGNvcmUgYXV0aG9ycyBvZg0K PiA+ICAgIHRoZSBET1RTIHJlcXVpcmVtZW50cyBXRyBkcmFmdHMsIHdoaWNoIGd1YXJhbnRlZXMg Y29uc2lzdGVuY3kNCj4gYmV0d2Vlbg0KPiA+ICAgIHRoZSBjb3JlIERPVFMgcHJvdG9jb2wgZG9j dW1lbnRzLiAgVW50aWwgbm93LCB0aGVyZSBhcmUgdGhyZWUgZGVtbw0KPiA+ICAgIGltcGxlbWVu dGF0aW9ucyBmb3IgaXQgKG9wZW4gc291cmNlIGdvLWRvdHMgZnJvbSBOVFQgYW5kIHR3bw0KPiA+ ICAgIHByb3ByaWV0YXJ5IGRlbW9zIGZyb20gTkNDIGFuZCBIdWF3ZWkpLCBhbmQgc2V2ZXJhbCBy b3VuZHMgb2YgaW50ZXJvcA0KPiA+ICAgIHRlc3RzIGR1cmluZyBJRVRGIGhhY2thdGhvbiBhY3Rp dml0aWVzLiBBbGwgdGhlIHRlY2huaWNhbCBpc3N1ZXMNCj4gPiAgICBpZGVudGlmaWVkIGJ5IHRo ZXNlIGRlbW9zIGFuZCB0aGUgZmluaXNoZWQgdGVzdHMgaGF2ZSBiZWVuIGFkZHJlc3NlZA0KPiA+ ICAgIGFuZCByZWZsZWN0ZWQgaW50byB0aGUgbGF0ZXN0IGRyYWZ0LCB3aGljaCBhcmUgdmVyeSBo ZWxwZnVsIGZvciB0aGUNCj4gPiAgICBjb21wbGV0ZW5lc3MgYW5kIHF1YWxpdHkgaW1wcm92ZW1l bnQgb2YgdGhlIGRyYWZ0Lg0KPiA+DQo+ID4gICAgSUFOQSBwb3J0IG51bWJlciBleHBlcnQgcmV2 aWV3IGlzIG9uZ29pbmc7IHRoZSBleHBlcnQgaXMgc2Vla2luZw0KPiA+ICAgIGFkZGl0aW9uYWwg anVzdGlmaWNhdGlvbiB0aGF0IGEgZGVkaWNhdGVkIHBvcnQgaXMgbmVlZGVkLCB3aGljaCBoYXMN Cj4gPiAgICBiZWVuIHByb3ZpZGVkIGJ5IHRoZSBkb2N1bWVudCBhdXRob3JzLg0KPiA+DQo+ID4g UGVyc29ubmVsDQo+ID4NCj4gPiAgICAgVGhlIGRvY3VtZW50IHNoZXBoZXJkIGlzIExpYW5nIFhp YS4gVGhlIHJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgaXMNCj4gPiAgICAgQmVuamFtaW4gS2Fk dWsuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= From nobody Wed Jan 8 05:43:12 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 D046C1200B6; Wed, 8 Jan 2020 05:43:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <157849099074.22624.12224252557438593742@ietfa.amsl.com> Date: Wed, 08 Jan 2020 05:43:10 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-08.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, 08 Jan 2020 13:43:11 -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-08.txt Pages : 23 Date : 2020-01-08 Abstract: It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure DOTS clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-08 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 Jan 9 05:12: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 92B101200C1; Thu, 9 Jan 2020 05:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZEWRrNDf4Oa; Thu, 9 Jan 2020 05:12:13 -0800 (PST) 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 CE35212007A; Thu, 9 Jan 2020 05:12:13 -0800 (PST) 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=vqIIPH4f+zhFTRUTUzdgc8PCUJlQsOLM/fyIMzsxtU4=; b=Wy6KaXCKTUYJmb3Nk8w92Tv3px xpQWiXeJ84UFCgX8mM2bjTl5M/3B8t2LVfOaPWR6X/MSIt3+3JUDydGtQcHrKwTI6qGg0WOw8eRKS 8R8UJpW/W2qOwefIGH6nTYx7QypAt5woJfZ2hZAHHJy44xv11rXmG7tB5gN/WJZhAlgFdf9oMOuaL Vu7jj3sjJhDUfDhgE5DTwEqA7pUKct5udx8qddyWkW39TzINSg1ri5l10x8/Iw9QHKx1TNAWykzw9 c4PFBbOx8V/RmCyad7liYvUW1mRvSWrJkyDP8vatMemCYZn57FgYEahh2fCpdIlmVCbkcbE5xQmLV Ey5v8NEQ==; Received: from [82.138.51.4] (port=50362 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from ) id 1ipXbe-0001g0-Px; Thu, 09 Jan 2020 08:12:11 -0500 From: "Valery Smyslov" To: , , Cc: , Date: Thu, 9 Jan 2020 16:12:12 +0300 Message-ID: <08ff01d5c6ee$699d4bd0$3cd7e370$@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: AdXG7akuBKoRNnebQIeoV76IWN824Q== 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 X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Dots] IPR disclouser for draft-ietf-dots-signal-call-home-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:12:15 -0000 Hi, while preparing shepherd write-up for draft-ietf-dots-signal-call-home-07 I should collect confirmations from each author and contributor that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Please confirm this by replying to this message. Note, that three IPR disclosures are currently filed for this draft: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-dots-signal-call-home Regards, Valery. From nobody Thu Jan 9 05:14:29 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D13120048; Thu, 9 Jan 2020 05:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fjzCFxfNOHbT; Thu, 9 Jan 2020 05:14:25 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E77A012001E; Thu, 9 Jan 2020 05:14:24 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 83F647CF7271763960CA; Thu, 9 Jan 2020 13:14:22 +0000 (GMT) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 9 Jan 2020 13:14:22 +0000 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 9 Jan 2020 21:14:19 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Thu, 9 Jan 2020 21:14:19 +0800 From: "Panwei (William)" To: Valery Smyslov , "draft-ietf-dots-signal-call-home@ietf.org" , "harsha_joshi@mcafee.com" CC: "dots-chairs@ietf.org" , "dots@ietf.org" Thread-Topic: IPR disclouser for draft-ietf-dots-signal-call-home-07 Thread-Index: AdXG7akuBKoRNnebQIeoV76IWN824QAAOsdw Date: Thu, 9 Jan 2020 13:14:19 +0000 Message-ID: <92cc02d3f9fd41ba9080e8f5873ea9aa@huawei.com> References: <08ff01d5c6ee$699d4bd0$3cd7e370$@smyslov.net> In-Reply-To: <08ff01d5c6ee$699d4bd0$3cd7e370$@smyslov.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.152] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] IPR disclouser for draft-ietf-dots-signal-call-home-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:14:27 -0000 SGksIA0KDQpJIGRvbid0IGhhdmUgbm9yIEknbSBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8g dGhpcyBkcmFmdC4NCg0KUmVnYXJkcyAmIFRoYW5rcyENCsXLzrAgV2VpIFBhbg0Ku6rOqry8yvXT 0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVmFsZXJ5IFNteXNsb3YgW21haWx0bzp2YWxlcnlAc215 c2xvdi5uZXRdDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDksIDIwMjAgOToxMiBQTQ0KPiBU bzogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7IGhhcnNoYV9qb3No aUBtY2FmZWUuY29tOw0KPiBQYW53ZWkgKFdpbGxpYW0pIDx3aWxsaWFtLnBhbndlaUBodWF3ZWku Y29tPg0KPiBDYzogZG90cy1jaGFpcnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogSVBSIGRpc2Nsb3VzZXIgZm9yIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLTA3 DQo+IA0KPiBIaSwNCj4gDQo+IHdoaWxlIHByZXBhcmluZyBzaGVwaGVyZCB3cml0ZS11cCBmb3Ig ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWUtMDcNCj4gSSBzaG91bGQgY29sbGVjdCBj b25maXJtYXRpb25zIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yIHRoYXQgYW55DQo+ IGFuZCBhbGwgYXBwcm9wcmlhdGUgSVBSIGRpc2Nsb3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNv bmZvcm1hbmNlIHdpdGggdGhlDQo+IHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2 ZSBhbHJlYWR5IGJlZW4gZmlsZWQuDQo+IA0KPiBQbGVhc2UgY29uZmlybSB0aGlzIGJ5IHJlcGx5 aW5nIHRvIHRoaXMgbWVzc2FnZS4NCj4gDQo+IE5vdGUsIHRoYXQgdGhyZWUgSVBSIGRpc2Nsb3N1 cmVzIGFyZSBjdXJyZW50bHkgZmlsZWQgZm9yIHRoaXMgZHJhZnQ6DQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/c3VibWl0PWRyYWZ0JmlkPWRyYWZ0LWlldGYtZG90 cy1zaQ0KPiBnbmFsLWNhbGwtaG9tZQ0KPiANCj4gUmVnYXJkcywNCj4gVmFsZXJ5Lg0KDQo= From nobody Thu Jan 9 05:42: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 B46CF12009E; Thu, 9 Jan 2020 05:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUTsb8coj4UP; Thu, 9 Jan 2020 05:41:59 -0800 (PST) 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 895EC12001E; Thu, 9 Jan 2020 05:41:59 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1ipY4R-0003K1-Nu; Thu, 09 Jan 2020 13:41:55 +0000 From: "Jon Shallow" To: "'Valery Smyslov'" , , , , "'Panwei \(William\)'" , References: <08ff01d5c6ee$699d4bd0$3cd7e370$@smyslov.net> In-Reply-To: <08ff01d5c6ee$699d4bd0$3cd7e370$@smyslov.net> Date: Thu, 9 Jan 2020 13:41:53 -0000 Message-ID: <043101d5c6f2$8d2f24c0$a78d6e40$@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: AQGfoZSEaD1TYWHJC7vC/SNcmOGEz6hOndOg Content-Language: en-gb Archived-At: Subject: Re: [Dots] IPR disclouser for draft-ietf-dots-signal-call-home-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:42:02 -0000 Hi, I confirm that I do not have, nor aware of any IPR (other than the 3 disclosures below which I am not a part of) related to this draft. Regards Jon > -----Original Message----- > From: Valery Smyslov [mailto:ietf-supjps-valery@smyslov.net] > Sent: 09 January 2020 13:12 > To: draft-ietf-dots-signal-call-home@ietf.org; harsha_joshi@mcafee.com; > william.panwei@huawei.com > Cc: dots-chairs@ietf.org; dots@ietf.org > Subject: IPR disclouser for draft-ietf-dots-signal-call-home-07 > > Hi, > > while preparing shepherd write-up for draft-ietf-dots-signal-call-home-07 > I should collect confirmations from each author and contributor that > any and all appropriate IPR disclosures required for full conformance > with the provisions of BCP 78 and BCP 79 have already been filed. > > Please confirm this by replying to this message. > > Note, that three IPR disclosures are currently filed for this draft: > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-dots- > signal-call-home > > Regards, > Valery. From nobody Thu Jan 9 05:43:05 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA331200C1 for ; Thu, 9 Jan 2020 05:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJWSF7fIQszm for ; Thu, 9 Jan 2020 05:43:01 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2431712009E for ; Thu, 9 Jan 2020 05:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578577380; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Yk+edP/E8qgFBurynf5SKOVh9VW3xq4wUaGh7OjrONs=; b=BUDi0g/4s5Sb1BjydP9itK5Knf0KnC0PIErmQBRWGcoVXhVHrJreB2crdOkXjbP3Cw7sX0 z0oTzLnTYF+gP4nAnesE172LUWQcJrAjYEFlKy55Hmqq885Fy26e/W9nYV0WsuCpTxG273 o68yZqvzYuLS+G62vhZaEY0YMXdf9Cw= Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-169-ygdw_J41MRyTUM9AMztDng-1; Thu, 09 Jan 2020 08:42:58 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1127.namprd16.prod.outlook.com (10.172.115.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 13:42:56 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea%6]) with mapi id 15.20.2602.018; Thu, 9 Jan 2020 13:42:56 +0000 From: "Konda, Tirumaleswar Reddy" To: "Panwei (William)" , Valery Smyslov , "draft-ietf-dots-signal-call-home@ietf.org" , "Joshi, Harsha" CC: "dots-chairs@ietf.org" , "dots@ietf.org" Thread-Topic: IPR disclouser for draft-ietf-dots-signal-call-home-07 Thread-Index: AQHVxu6+rEe2u5vREkKGb5LFrobL3qfiVcHQ Date: Thu, 9 Jan 2020 13:42:56 +0000 Message-ID: References: <08ff01d5c6ee$699d4bd0$3cd7e370$@smyslov.net> <92cc02d3f9fd41ba9080e8f5873ea9aa@huawei.com> In-Reply-To: <92cc02d3f9fd41ba9080e8f5873ea9aa@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7ed98a09-825e-4d86-6402-08d79509d577 x-ms-traffictypediagnostic: CY4PR1601MB1127: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(396003)(136003)(376002)(32952001)(13464003)(199004)(189003)(52536014)(66946007)(5660300002)(110136005)(64756008)(66556008)(71200400001)(53546011)(7696005)(86362001)(6506007)(966005)(76116006)(26005)(66446008)(81166006)(81156014)(54906003)(66476007)(4326008)(55016002)(9686003)(6636002)(2906002)(316002)(8936002)(478600001)(8676002)(33656002)(186003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1127; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vGFsn9js2jo2l+SzglLGc7vwcS1rrQTXz0ueS9gTUOCZvkJh4Oi1x/RMYtgh8LhjlPEtgBWuyz5JleyL++Y+f1h47VzZowz2TzHQrAzCOEPhji09aa/9PVsg7XPgO5GOHwMIx+BmZWlKQVnMUFcydX+IZSNfqeaU7eeC7KU+TJM7JWSzd9K+HsRJPqXlKcElbMh/Rd2k6Sijew8SvsRnusswyWsDWPhB0KHBGWFWGaWODt4cKb8bk1XSNM9qyNCePuwpmRqPcahcHvwTd9ZlsK82Bq0igKfRsNwiYAkA+6Olt04P6yiCyosbJjHtOO2w+cxE8FMzvcYGpW+wUHRO2JNsN6OC5vUzbwAnhKgjOj6c0gxWhKPBB9scoeUor0apYbKvuvesgYlahfW7OA2Vo23I94r3PZa/IwcrmymZb2Y+OBsOgi07L+Vfsu3uSx2mWGKdNfbVffAJO9x1Hqkft9rWFoFl6Q+mA4fpnkzqDfE/DH/xgwVTFIX3MSOuMbPlp/HyzTJuUFrZYHuUX6eWXr/RtVN/BcYuj4pxTfgQd8QljSFgctjVlxterW8vQ070Pi0yMhXD37DW1KzQqAbgbYzHDfhUgQQ3rOwkgosWZ3qzG3uj7ZdIcHoYuQRq865w MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ed98a09-825e-4d86-6402-08d79509d577 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 13:42:56.4320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I5J3OCvGmIWBjIxkBoj+pSBOIBqV1xcZIezp/asSwDnlEf8VDjLNePWWSjTKXXhUiE0zh72rTDLel3Jng5wV6jdXQ4xRj12/YZ7/LEvCj8x+fdeEUscgl618ORH7sVjY X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1127 X-MC-Unique: ygdw_J41MRyTUM9AMztDng-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Dots] IPR disclouser for draft-ietf-dots-signal-call-home-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:43:04 -0000 SGkgVmFybGV5LA0KDQpNY0FmZWUgZGlzY2xvc2VkIElQUiB3aGVuIDAwIHZlcnNpb24gb2YgdGhl IGRyYWZ0IHdhcyBwdWJsaXNoZWQuIEkgZG9uJ3QgaGF2ZSBhbnkgb3RoZXIgSVBSIHJlbGF0ZWQg dG8gdGhpcyBkcmFmdCBub3IgYXdhcmUgb2YgYW55IG90aGVyIElQUiByZWxhdGVkIHRvIHRoaXMg ZHJhZnQgKG90aGVyIHRoYW4gdGhlIG9uZXMgZnJvbSBPcmFuZ2UpLg0KDQpDaGVlcnMsDQotVGly dQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvdHMgPGRvdHMtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFBhbndlaSAoV2lsbGlhbSkNCj4gU2VudDogVGh1 cnNkYXksIEphbnVhcnkgOSwgMjAyMCA2OjQ0IFBNDQo+IFRvOiBWYWxlcnkgU215c2xvdiA8dmFs ZXJ5QHNteXNsb3YubmV0PjsgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLQ0KPiBob21lQGll dGYub3JnOyBKb3NoaSwgSGFyc2hhIDxoYXJzaGFfam9zaGlAbWNhZmVlLmNvbT4NCj4gQ2M6IGRv dHMtY2hhaXJzQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRG90c10g SVBSIGRpc2Nsb3VzZXIgZm9yIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLTA3DQo+ IA0KPiBDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4g YXR0YWNobWVudHMgdW5sZXNzIHlvdQ0KPiByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0 aGUgY29udGVudCBpcyBzYWZlLg0KPiANCj4gSGksDQo+IA0KPiBJIGRvbid0IGhhdmUgbm9yIEkn bSBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NCj4gDQo+IFJlZ2FyZHMg JiBUaGFua3MhDQo+IOa9mOS8nyBXZWkgUGFuDQo+IOWNjuS4uuaKgOacr+aciemZkOWFrOWPuCBI dWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBWYWxlcnkgU215c2xvdiBbbWFpbHRvOnZhbGVyeUBzbXlz bG92Lm5ldF0NCj4gPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA5LCAyMDIwIDk6MTIgUE0NCj4g PiBUbzogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWVAaWV0Zi5vcmc7DQo+ID4gaGFy c2hhX2pvc2hpQG1jYWZlZS5jb207IFBhbndlaSAoV2lsbGlhbSkNCj4gPHdpbGxpYW0ucGFud2Vp QGh1YXdlaS5jb20+DQo+ID4gQ2M6IGRvdHMtY2hhaXJzQGlldGYub3JnOyBkb3RzQGlldGYub3Jn DQo+ID4gU3ViamVjdDogSVBSIGRpc2Nsb3VzZXIgZm9yIGRyYWZ0LWlldGYtZG90cy1zaWduYWwt Y2FsbC1ob21lLTA3DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IHdoaWxlIHByZXBhcmluZyBzaGVw aGVyZCB3cml0ZS11cCBmb3INCj4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS0w Nw0KPiA+IEkgc2hvdWxkIGNvbGxlY3QgY29uZmlybWF0aW9ucyBmcm9tIGVhY2ggYXV0aG9yIGFu ZCBjb250cmlidXRvciB0aGF0DQo+ID4gYW55IGFuZCBhbGwgYXBwcm9wcmlhdGUgSVBSIGRpc2Ns b3N1cmVzIHJlcXVpcmVkIGZvciBmdWxsIGNvbmZvcm1hbmNlDQo+ID4gd2l0aCB0aGUgcHJvdmlz aW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxlZC4NCj4gPg0K PiA+IFBsZWFzZSBjb25maXJtIHRoaXMgYnkgcmVwbHlpbmcgdG8gdGhpcyBtZXNzYWdlLg0KPiA+ DQo+ID4gTm90ZSwgdGhhdCB0aHJlZSBJUFIgZGlzY2xvc3VyZXMgYXJlIGN1cnJlbnRseSBmaWxl ZCBmb3IgdGhpcyBkcmFmdDoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9z ZWFyY2gvP3N1Ym1pdD1kcmFmdCZpZD1kcmFmdC1pZXRmLWRvDQo+ID4gdHMtc2kNCj4gPiBnbmFs LWNhbGwtaG9tZQ0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBWYWxlcnkuDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxpbmcg bGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG90cw0KDQo= From nobody Thu Jan 9 06:45: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 0A5F6120862; Thu, 9 Jan 2020 06:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 p684D-CoOOp2; Thu, 9 Jan 2020 06:45:02 -0800 (PST) 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 711131208C8; Thu, 9 Jan 2020 06:45:02 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 47tpms1Hw5zybf; Thu, 9 Jan 2020 15:45:01 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 47tpms0WLHzDq75; Thu, 9 Jan 2020 15:45:01 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 9 Jan 2020 15:45:00 +0100 From: To: Valery Smyslov , "draft-ietf-dots-signal-call-home@ietf.org" , "harsha_joshi@mcafee.com" , "william.panwei@huawei.com" CC: "dots-chairs@ietf.org" , "dots@ietf.org" Thread-Topic: IPR disclouser for draft-ietf-dots-signal-call-home-07 Thread-Index: AdXG7akuBKoRNnebQIeoV76IWN824QADRvfA Date: Thu, 9 Jan 2020 14:45:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314067D7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <08ff01d5c6ee$699d4bd0$3cd7e370$@smyslov.net> In-Reply-To: <08ff01d5c6ee$699d4bd0$3cd7e370$@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] IPR disclouser for draft-ietf-dots-signal-call-home-07 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:45:07 -0000 Hi Valery,=20 I confirm.=20 I'm not aware of any IPRs other than those already disclosed.=20 Cheers, Med > -----Message d'origine----- > De=A0: Valery Smyslov [mailto:valery@smyslov.net] > Envoy=E9=A0: jeudi 9 janvier 2020 14:12 > =C0=A0: draft-ietf-dots-signal-call-home@ietf.org; harsha_joshi@mcafee.co= m; > william.panwei@huawei.com > Cc=A0: dots-chairs@ietf.org; dots@ietf.org > Objet=A0: IPR disclouser for draft-ietf-dots-signal-call-home-07 >=20 > Hi, >=20 > while preparing shepherd write-up for draft-ietf-dots-signal-call-home- > 07 > I should collect confirmations from each author and contributor that > any and all appropriate IPR disclosures required for full conformance > with the provisions of BCP 78 and BCP 79 have already been filed. >=20 > Please confirm this by replying to this message. >=20 > Note, that three IPR disclosures are currently filed for this draft: > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf- > dots-signal-call-home >=20 > Regards, > Valery. From nobody Thu Jan 9 07:40: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 EAA4B120073; Thu, 9 Jan 2020 07:39:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <157858439484.11849.777634754997227123@ietfa.amsl.com> Date: Thu, 09 Jan 2020 07:39:54 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-09.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, 09 Jan 2020 15:39:55 -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-09.txt Pages : 24 Date : 2020-01-09 Abstract: It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure DOTS clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-09 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 Jan 9 13:30: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 11A0512081C for ; Thu, 9 Jan 2020 13:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lUIB3zWg0Nv for ; Thu, 9 Jan 2020 13:30:12 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 A4D8212080F for ; Thu, 9 Jan 2020 13:30:12 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 009LUBXs013598 for ; Thu, 9 Jan 2020 16:30:11 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 009LUBXs013598 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1578605411; bh=tEhymZuRjLrHMlepqxEHovlsxOR45ehB640/UFMuI+s=; h=From:To:Subject:Date:From; b=OEkeCLPOclzqW/Z/gZ9eMszM1eBim5ABcE7Yy/JatcA8GBZMzfGvOqPXUNesZTfSj ihQTU7OiDHgdOZIAbhZUVZoy2nzyxJ4oQEcZJsq7ynX+N52wZv+4qHbMPJ1NBDD7Fd 1g34t7bRwvlOgVoVZLT4KQcfDTL+GmausNTAsp5o= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 009LU9gx010567 for ; Thu, 9 Jan 2020 16:30:09 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Thu, 9 Jan 2020 16:30:09 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: AD Review of draft-ietf-dots-architecture-14 Thread-Index: AdXHMmoiRx3D3KUrRUiecOSiRVyATg== Date: Thu, 9 Jan 2020 21:30:09 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E7100170@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] AD Review of draft-ietf-dots-architecture-14 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:30:16 -0000 Hello! The following is my AD review of draft-ietf-dots-architecture-14: ** Section 1.2. Per "In this architecture, DOTS clients and servers commun= icate using DOTS signaling ...", is this definition too narrow? Per the gu= idance in Section 1.1.2 to use RFC8612 definitions, which says that "DOTS s= ignal: [is a] A status/control message transmitted over the authenticated = signal channel ..." the text seems to ignoring the data channel. ** Section 1.2. Along the same line, the next sentence, "As a result of si= gnals from the DOTS client ...", seems to also present a very narrow exampl= e of what the signal channel might do (let alone the data channel). I'm no= t sure how much this sentence adds to clarifying the scope as suggested by = the section title. ** Section. 1.3 Per "The signal and data channels are loosely coupled, and= may not terminate on the same DOTS server", it seems help to clarify the o= bvious that how these signals would be synchronized is out of scope. ** Section 2. Figure 3. Is this figure (i.e., the JSON example) normative= ? This seems like a detail best left to the data channel spec (and omitted= from this document). ** Section 2. Per: Note that while it is possible to exchange the above information before, during or after a DDoS attack, DOTS requires reliable delivery of this information and does not provide any special means for ensuring timely delivery of it during an attack. In practice, this means that DOTS deployments should not rely on such information being exchanged during a DDoS attack. It seems to me that there is guidance missing here. If the first sentence = says that this information can be exchanged before, during or after an atta= ck, but don't count on it during the attack. The second sentence reiterate= s the point that during an attack it will be unreliable, is a statement to = the effect that necessary configuration must be made prior to the attack al= so needed? ** Section 2.1 Per "It is not until this point that the mitigation service= is available for use.", this closing point about a mitigation service foll= ows from the previous description. However, I wanted to point out, the not= ion of a "mitigation service" being available after a fully configured DOTS= client is not a construct previously used in the document or the terminolo= gy. It's likely worth relating it to the previously defined terms like mit= igator. ** Section 2.1. To avoid confusion on terms (i.e., from HTTP), perhaps rep= lace s/basic authorization/authorization/. ** Section 2.2.2. Per "For a given DOTS client (administrative) domain, th= e DOTS server needs to be able to determine whether a given target resourc= e is in that domain.", what is a "target resource" isn't clear. I think it= is meant to be the resource that is the target of the attack (that the DOT= S client is signaling about). Also, the idea that DOTS clients have "domai= ns" is a new concept here that needs clarification. ** Section 2.2.2. Per "The DOTS server enforces authorization of DOTS clien= ts' signals for mitigation.", no objection. Is there a complementary state= ment to make the data channel? ** Section 5. Per "Any attacker with the ability to impersonate ...", this= paragraph clearly describes in the impact of impersonation. However, the = suggested mitigations read like requirements. Instead of trying to list th= em again, I would recommend explicitly citing the relevant requirements fro= m Section 2.4 of the RFC8612 and noting that need for conformance to these = security mechanisms. ** Section 5. Per "Similarly, received data at rest SHOULD be stored with = a satisfactory degree of security.", I would recommend explaining why the d= ata should be secured. Perhaps: OLD:=20 Similarly, received data at rest SHOULD be stored with a satisfactory degree of security. NEW (or something like it): Similarly, as the received data may contain network topology, telemetry, th= reat, or preconfigured mitigation information which could be considered sen= sitive in certain environment, it SHOULD be protected at rest per required = local policy. ** Section 5. Per "As many mitigation systems employ diversion to scrub at= tack traffic, operators of DOTS agents SHOULD ensure DOTS sessions are resi= stant to Man-in-the-Middle (MitM) attacks.", I'm not following the link bet= ween the mitigation systems re-routing traffic with DOTS agents resisting M= itM attack. What actions should be agents be taking? ** Section 5. Per: Any attack targeting the availability of DOTS servers may disrupt the ability of the system to receive and process DOTS signals resulting in failure to fulfill a mitigation request. DOTS agents SHOULD be given adequate protections, again in accordance with best current practices for network and host security. -- The first sentence talks about "DOTS servers". The second talk about pr= otecting "DOTS agents". What's the role in the DOTS clients in this guidan= ce? -- Shouldn't the protections afforded to the DOTS agents be a mandatory (MU= ST)? ** Editorial Nits: -- Section 1. Editorial. s/for help defending/for help to defend/ -- Section 3.2.5. Typo. s/deployements/deployments/ From nobody Fri Jan 10 00:36:18 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 4A468120058; Fri, 10 Jan 2020 00:36:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, iesg-secretary@ietf.org, dots@ietf.org Message-ID: <157864537729.27678.1708536003815879763.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2020 00:36:17 -0800 Archived-At: Subject: [Dots] Publication has been requested for draft-ietf-dots-server-discovery-09 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 08:36:17 -0000 Valery Smyslov has requested publication of draft-ietf-dots-server-discovery-09 as Proposed Standard on behalf of the DOTS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ From nobody Fri Jan 10 01:05: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 9A73012002E for ; Fri, 10 Jan 2020 01:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HYH6iAI8QuX for ; Fri, 10 Jan 2020 01:05:02 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A1B1200CE for ; Fri, 10 Jan 2020 01:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578647100; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Md0hb31TDeHYxbglwezNlMTzSYBpkCqvirrqgXC8r1I=; b=S0jg0et7sZ8lcUw/gFkXHg0yABW9GfHOtTxoATjkcy0Xc1wSB5hKQW7mbWuKh9EqGoTQAj vdBthDlJE5EY92jBM7FmB7sLdwRmYdLb1TtGGYGnlsveYiuVDpqG5mIrlF5F0Ql3JqbUcz eAJPV42VFkglnmnZsfczuV8FHpck5yM= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2174.outbound.protection.outlook.com [104.47.59.174]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-118-RzYWmhi4NSyc_fyZADaBqg-1; Fri, 10 Jan 2020 04:04:56 -0500 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1308.namprd16.prod.outlook.com (10.172.85.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 10 Jan 2020 09:04:54 +0000 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4%3]) with mapi id 15.20.2623.013; Fri, 10 Jan 2020 09:04:54 +0000 From: "Konda, Tirumaleswar Reddy" To: Roman Danyliw , "dots@ietf.org" Thread-Topic: AD Review of draft-ietf-dots-architecture-14 Thread-Index: AdXHMmoiRx3D3KUrRUiecOSiRVyATgAQ2HbA Date: Fri, 10 Jan 2020 09:04:54 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01E7100170@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01E7100170@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d29914d-4904-4bc9-7881-08d795ac2886 x-ms-traffictypediagnostic: DM5PR1601MB1308: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(346002)(39860400002)(396003)(32952001)(51914003)(13464003)(199004)(189003)(110136005)(26005)(316002)(55016002)(33656002)(9686003)(53546011)(6506007)(7696005)(66556008)(186003)(66446008)(86362001)(5660300002)(81156014)(66946007)(71200400001)(66476007)(81166006)(478600001)(64756008)(2906002)(8936002)(52536014)(76116006)(966005)(8676002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1308; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OX4kCwq0ZqHd3VB1l5RtBxT+icYo1ZoswdYRZ/aeuwzBYP2sEuAeVxwcFt5brmPmqHJpv8vBPheKhqlVYh162MqrMzoqKA21yisB0Ax/QuUEVh5iTFZUxXD/PXzkrlIOdh317X6bbqJwn+z3gYlBPAI8ACGmGwqB4+CtPjSAFUVAklVbst/276IGG0Y3syKYQocnU8DN9WtD+yn52DlbTV8+Wc2wx1x8FVJ1+qVXyu/o75imltUSIOgwU16nzRNDqj1zZamI5FcTn2FqAiqBLBrnyz9X+ZUc3NH/hSVy21VSZxwOqj7nuLYyjMikSjVmGc8Yt1wtkm30qHg5vIyewhyJwKypjZdrQxs8ZMTAStiiIvMLfeOw8ZGsup4iS5V1wWUov8OSGZ2+H1wIrGlTCDM9hXoqdvG0jjBc1lDDHsV9KX5/TC032fstLoNRlI6z1eE+eV+rFnprecaxePPXfPFFXsCVw3A2qwJR6oQlNdTEHO/wovZ/fxs1Fd50goy651a1xy5aYPmXy5TZwbtWCHCO9kNaRGivcvbJxrQO0X3Bh8CT2ECeSYZLBoUk8+k4YjychDd0DyKOTmaLpTaNuT4SWSafaBwYPyoXvzwpG0c= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d29914d-4904-4bc9-7881-08d795ac2886 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 09:04:54.2349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QtgmqWxehPTPSetrXz2AExVe8WuwuFMIWWt7IRpkGZn21+HdeVOVcWtk7rkShNEEnojsomaPBRBj2ffU29NuLxkDKczrV4w0oVm2fM79QwxPPUDhy/04LLIJZTUQ9XTr X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1308 X-MC-Unique: RzYWmhi4NSyc_fyZADaBqg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] AD Review of draft-ietf-dots-architecture-14 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, 10 Jan 2020 09:05:07 -0000 Hi Roman, Thanks for the review. Please see inline > -----Original Message----- > From: Dots On Behalf Of Roman Danyliw > Sent: Friday, January 10, 2020 3:00 AM > To: dots@ietf.org > Subject: [Dots] AD Review of draft-ietf-dots-architecture-14 >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Hello! >=20 > The following is my AD review of draft-ietf-dots-architecture-14: >=20 > ** Section 1.2. Per "In this architecture, DOTS clients and servers > communicate using DOTS signaling ...", is this definition too narrow? Pe= r the > guidance in Section 1.1.2 to use RFC8612 definitions, which says that "DO= TS > signal: [is a] A status/control message transmitted over the authenticat= ed > signal channel ..." the text seems to ignoring the data channel. Updated line as follows: In this architecture, DOTS clients and servers communicate using DOTS signa= l channel and data channel protocols. >=20 > ** Section 1.2. Along the same line, the next sentence, "As a result of = signals > from the DOTS client ...", seems to also present a very narrow example of > what the signal channel might do (let alone the data channel). I'm not s= ure > how much this sentence adds to clarifying the scope as suggested by the > section title. Agreed, I don't see a need for this sentence in the "Scope" section. Remove= d it.=20 >=20 > ** Section. 1.3 Per "The signal and data channels are loosely coupled, a= nd > may not terminate on the same DOTS server", it seems help to clarify the > obvious that how these signals would be synchronized is out of scope. Okay, added the following line: How the DOTS servers synchronize the DOTS configuration is out of scope of = this specification. >=20 > ** Section 2. Figure 3. Is this figure (i.e., the JSON example) normati= ve? No. This > seems like a detail best left to the data channel spec (and omitted from = this > document). Yes, we have an example in the data channel spec. Removed Figure 3.=20 >=20 > ** Section 2. Per: > Note that while it is possible to exchange the above information > before, during or after a DDoS attack, DOTS requires reliable > delivery of this information and does not provide any special means > for ensuring timely delivery of it during an attack. In practice, > this means that DOTS deployments should not rely on such information > being exchanged during a DDoS attack. >=20 > It seems to me that there is guidance missing here. If the first sentenc= e says > that this information can be exchanged before, during or after an attack,= but > don't count on it during the attack. The second sentence reiterates the = point > that during an attack it will be unreliable, is a statement to the effect= that > necessary configuration must be made prior to the attack also needed? Yes, updated last line as follows: In practice, this means that DOTS deployments should rely on such informati= on=20 being exchanged only under normal traffic conditions. >=20 > ** Section 2.1 Per "It is not until this point that the mitigation servi= ce is > available for use.", this closing point about a mitigation service follow= s from > the previous description. However, I wanted to point out, the notion of = a > "mitigation service" being available after a fully configured DOTS client= is not > a construct previously used in the document or the terminology. It's lik= ely > worth relating it to the previously defined terms like mitigator. "mitigation service" is already used in Sections 2 and 1.2 >=20 > ** Section 2.1. To avoid confusion on terms (i.e., from HTTP), perhaps > replace s/basic authorization/authorization/. Okay, replaced. >=20 > ** Section 2.2.2. Per "For a given DOTS client (administrative) domain, = the > DOTS server needs to be able to determine whether a given target resourc= e > is in that domain.", what is a "target resource" isn't clear. I think it= is meant to > be the resource that is the target of the attack (that the DOTS client is > signaling about).=20 Yes. > Also, the idea that DOTS clients have "domains" is a new > concept here that needs clarification. I have simplified the text as follows: For a given DOTS client (administrative) domain, the DOTS server needs to b= e able to determine whether a given resource is in that domain. For example, this could take the form of associating a set of IP addresses and/= or prefixes per DOTS client domain. >=20 > ** Section 2.2.2. Per "The DOTS server enforces authorization of DOTS > clients' signals for mitigation.", no objection. Is there a complementar= y > statement to make the data channel? Good point, updated text as follows: The DOTS server enforces authorization of signals for mitigation, filtering= rules and aliases for resources from DOTS clients. =20 The mechanism of enforcement is not in scope for this document, but is expe= cted to restrict mitigation requests, filtering rules and aliases scope to addresses, prefixes, and/or services owned by the DOTS client doma= in, such that a DOTS client from one domain is not able to influence the network path to another domain. A DOTS server MUST reject requests for mitigation of resources, fil= tering rules and aliases for resources not owned by the requesting DOTS client's administrative domain. >=20 > ** Section 5. Per "Any attacker with the ability to impersonate ...", th= is > paragraph clearly describes in the impact of impersonation. However, the > suggested mitigations read like requirements. Instead of trying to list = them > again, I would recommend explicitly citing the relevant requirements from > Section 2.4 of the RFC8612 and noting that need for conformance to these > security mechanisms. Good point, updated paragraph as follows: Any attacker with the ability to impersonate a legitimate DOTS client or se= rver or, indeed, inject false messages into the stream may potentially trigger/withdraw traffic redirection, trigger/cancel mitigation activities = or subvert drop-/accept-lists. From an architectural standpoint, operators MU= ST ensure conformance to the security requirements defined in Section 2.4 of= =20 RFC8612 to secure data in transit.=20 >=20 > ** Section 5. Per "Similarly, received data at rest SHOULD be stored wit= h a > satisfactory degree of security.", I would recommend explaining why the > data should be secured. Perhaps: > OLD: > Similarly, received data at rest SHOULD be > stored with a satisfactory degree of security. >=20 > NEW (or something like it): > Similarly, as the received data may contain network topology, telemetry, > threat, or preconfigured mitigation information which could be considered > sensitive in certain environment, it SHOULD be protected at rest per requ= ired > local policy. Works for me, minor update to proposed text: Similarly, as the received data may contain network topology, telemetry, threat and mitigation information which could be considered sensitive in certain environment, it SHOULD be protected at rest per requir= ed local policy. =20 >=20 > ** Section 5. Per "As many mitigation systems employ diversion to scrub > attack traffic, operators of DOTS agents SHOULD ensure DOTS sessions are > resistant to Man-in-the-Middle (MitM) attacks.", I'm not following the li= nk > between the mitigation systems re-routing traffic with DOTS agents resist= ing > MitM attack. What actions should be agents be taking? Good point, modified paragraph as follows (and removed line discussing re-r= outing traffic): An attacker with control of a DOTS client may negatively influence network traffic by requesting and withdrawing requests for mitiga= tion for particular prefixes, leading to route or DNS flapping. DOTS operators s= hould carefully monitor and audit DOTS clients to detect misbehavior and deter misuse. >=20 > ** Section 5. Per: > Any attack targeting the availability of DOTS servers may disrupt the > ability of the system to receive and process DOTS signals resulting > in failure to fulfill a mitigation request. DOTS agents SHOULD be > given adequate protections, again in accordance with best current > practices for network and host security. > -- The first sentence talks about "DOTS servers". The second talk about > protecting "DOTS agents". What's the role in the DOTS clients in this > guidance? > -- Shouldn't the protections afforded to the DOTS agents be a mandatory > (MUST)? Good point, the guidance is only meant for DOTS servers and is mandatory. M= odified text as follows: DOTS servers MUST be given adequate protections, in accordance with best c= urrent practices for network and host security. >=20 > ** Editorial Nits: > -- Section 1. Editorial. s/for help defending/for help to defend/ > -- Section 3.2.5. Typo. s/deployements/deployments/ Thanks, Fixed. Cheers, -Tiru >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Jan 10 01:49:13 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B42E120814 for ; Fri, 10 Jan 2020 01:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yibCHRIl5J7a for ; Fri, 10 Jan 2020 01:49:10 -0800 (PST) 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 C1CE01201DE for ; Fri, 10 Jan 2020 01:49:09 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 47vJ8z6C3Rz8t7h; Fri, 10 Jan 2020 10:49:07 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 47vJ8z507Qz1xpF; Fri, 10 Jan 2020 10:49:07 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 10 Jan 2020 10:49:07 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Roman Danyliw" , "dots@ietf.org" Thread-Topic: AD Review of draft-ietf-dots-architecture-14 Thread-Index: AdXHMmoiRx3D3KUrRUiecOSiRVyATgAQ2HbAAAi9PtA= Date: Fri, 10 Jan 2020 09:49:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314072F3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC01E7100170@marchand> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD Review of draft-ietf-dots-architecture-14 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, 10 Jan 2020 09:49:11 -0000 Hi Tiru, all,=20 Two minor comments inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > Tirumaleswar Reddy > Envoy=E9=A0: vendredi 10 janvier 2020 10:05 > =C0=A0: Roman Danyliw; dots@ietf.org > Objet=A0: Re: [Dots] AD Review of draft-ietf-dots-architecture-14 >=20 > Hi Roman, >=20 > Thanks for the review. Please see inline >=20 > > -----Original Message----- > > From: Dots On Behalf Of Roman Danyliw > > Sent: Friday, January 10, 2020 3:00 AM > > To: dots@ietf.org > > Subject: [Dots] AD Review of draft-ietf-dots-architecture-14 > > > > CAUTION: External email. Do not click links or open attachments unless > you > > recognize the sender and know the content is safe. > > > > Hello! > > > > The following is my AD review of draft-ietf-dots-architecture-14: ... > > > > ** Section 2.1 Per "It is not until this point that the mitigation > service is > > available for use.", this closing point about a mitigation service > follows from > > the previous description. However, I wanted to point out, the notion > of a > > "mitigation service" being available after a fully configured DOTS > client is not > > a construct previously used in the document or the terminology. It's > likely > > worth relating it to the previously defined terms like mitigator. >=20 > "mitigation service" is already used in Sections 2 and 1.2 [Med] Given that only "mitigation" and "mitigator" are defined in the termi= nology inherited from RFC8612, I suggest to make this simple change: OLD:=20 A simple example instantiation of the DOTS architecture could be an enterprise as the attack target for a volumetric DDoS attack, and an upstream DDoS mitigation service as the mitigator. NEW: A simple example instantiation of the DOTS architecture could be an enterprise as the attack target for a volumetric DDoS attack, and an upstream DDoS mitigator. The service provided by the mitigator is called= : DDoS mitigation service. >=20 > > > > ** Section 2.1. To avoid confusion on terms (i.e., from HTTP), > perhaps > > replace s/basic authorization/authorization/. >=20 > Okay, replaced. >=20 > > > > ** Section 2.2.2. Per "For a given DOTS client (administrative) > domain, the > > DOTS server needs to be able to determine whether a given target > resource > > is in that domain.", what is a "target resource" isn't clear. I think > it is meant to > > be the resource that is the target of the attack (that the DOTS client > is > > signaling about). >=20 > Yes. >=20 > > Also, the idea that DOTS clients have "domains" is a new > > concept here that needs clarification. >=20 > I have simplified the text as follows: > For a given DOTS client (administrative) domain, the DOTS server needs > to be > able to determine whether a given resource is in that domain. For > example, this could take the form of associating a set of IP addresses > and/or > prefixes per DOTS client domain. [Med] Please make sure that the same wording is consistently used in the do= cument. Typically, please make these changes in many places of the document= : s/DOTS client's domain/DOTS client domain=20 s/DOTS server's domain/DOTS server domain This is also to be aligned with the signal channel document. Thanks.=20 From nobody Fri Jan 10 02:36:34 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F161200BA for ; Fri, 10 Jan 2020 02:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glCuvW6K3Bmr for ; Fri, 10 Jan 2020 02:36:31 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 08615120071 for ; Fri, 10 Jan 2020 02:36:30 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00AAaT3O030470; Fri, 10 Jan 2020 05:36:29 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 00AAaT3O030470 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1578652589; bh=J68R1GLLLohLtZxqWUt3l7rqQ4NX2+8iDnkR8275vZA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZvTvpWdV6Er1C+VTkIg/r3yi/MwdglQYxDTyRIy6lTOMP2AQdskiLVtq82EdsNZaM g8GOHZHBlbZRU7P1pJbhTeQevVnUL98Rd4A3/OQhzWtn93pMzl1PL09GJunrdjqw8H 6NgTjLkWAHfIHojOmavpVWkkWVXFa7QZH18oDh8Q= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00AAaSTm032317; Fri, 10 Jan 2020 05:36:28 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Fri, 10 Jan 2020 05:36:28 -0500 From: Roman Danyliw To: "Konda, Tirumaleswar Reddy" CC: "dots@ietf.org" Thread-Topic: AD Review of draft-ietf-dots-architecture-14 Thread-Index: AdXHMmoiRx3D3KUrRUiecOSiRVyATgAQ2HbAAAsA/cU= Date: Fri, 10 Jan 2020 10:36:27 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01E7100170@marchand>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD Review of draft-ietf-dots-architecture-14 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, 10 Jan 2020 10:36:33 -0000 SGkgVGlydSENCg0KRXZlcnl0aGluZyBwcm9wb3NlZCBiZWxvdyB3b3JrcyBmb3IgbWUgYW5kIGFk ZHJlc3NlcyBteSBjb25jZXJucy4gTWVk4oCZcyBzdWJzZXF1ZW50IGNvbnNpc3RlbmN5IGVkaXRz IG1ha2Ugc2Vuc2UgdG8gbWUgdG9vLg0KDQpUaGFua3MgZm9yIHRoZSBxdWljayB0dXJuIGFyb3Vu ZC4gSeKAmWxsIHN0YXJ0IHRoZSBJRVRGIExDIHdpdGggdGhlIC0xNSB0aGF0IGhhcyB0aGVzZSBj aGFuZ2VzLg0KDQpSb21hbg0KDQo+IE9uIEphbiAxMCwgMjAyMCwgYXQgNDowNSBBTSwgS29uZGEs IFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFAbWNhZmVlLmNvbT4g d3JvdGU6DQo+IA0KPiDvu79IaSBSb21hbiwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4g UGxlYXNlIHNlZSBpbmxpbmUNCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogRG90cyA8ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUm9tYW4gRGFu eWxpdw0KPj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDEwLCAyMDIwIDM6MDAgQU0NCj4+IFRvOiBk b3RzQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbRG90c10gQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYt ZG90cy1hcmNoaXRlY3R1cmUtMTQNCj4+IA0KPj4gQ0FVVElPTjogRXh0ZXJuYWwgZW1haWwuIERv IG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UNCj4+IHJlY29n bml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+PiANCj4+IEhl bGxvIQ0KPj4gDQo+PiBUaGUgZm9sbG93aW5nIGlzIG15IEFEIHJldmlldyBvZiBkcmFmdC1pZXRm LWRvdHMtYXJjaGl0ZWN0dXJlLTE0Og0KPj4gDQo+PiAqKiBTZWN0aW9uIDEuMi4gIFBlciAiSW4g dGhpcyBhcmNoaXRlY3R1cmUsIERPVFMgY2xpZW50cyBhbmQgc2VydmVycw0KPj4gY29tbXVuaWNh dGUgdXNpbmcgRE9UUyBzaWduYWxpbmcgLi4uIiwgaXMgdGhpcyBkZWZpbml0aW9uIHRvbyBuYXJy b3c/ICBQZXIgdGhlDQo+PiBndWlkYW5jZSBpbiBTZWN0aW9uIDEuMS4yIHRvIHVzZSBSRkM4NjEy IGRlZmluaXRpb25zLCB3aGljaCBzYXlzIHRoYXQgIkRPVFMNCj4+IHNpZ25hbDogIFtpcyBhXSBB IHN0YXR1cy9jb250cm9sIG1lc3NhZ2UgdHJhbnNtaXR0ZWQgb3ZlciB0aGUgYXV0aGVudGljYXRl ZA0KPj4gc2lnbmFsIGNoYW5uZWwgLi4uIiB0aGUgdGV4dCBzZWVtcyB0byBpZ25vcmluZyB0aGUg ZGF0YSBjaGFubmVsLg0KPiANCj4gVXBkYXRlZCBsaW5lIGFzIGZvbGxvd3M6DQo+IEluIHRoaXMg YXJjaGl0ZWN0dXJlLCBET1RTIGNsaWVudHMgYW5kIHNlcnZlcnMgY29tbXVuaWNhdGUgdXNpbmcg RE9UUyBzaWduYWwgY2hhbm5lbCBhbmQgZGF0YSBjaGFubmVsIHByb3RvY29scy4NCj4gDQo+PiAN Cj4+ICoqIFNlY3Rpb24gMS4yLiAgQWxvbmcgdGhlIHNhbWUgbGluZSwgdGhlIG5leHQgc2VudGVu Y2UsICJBcyBhIHJlc3VsdCBvZiBzaWduYWxzDQo+PiBmcm9tIHRoZSBET1RTIGNsaWVudCAuLi4i LCBzZWVtcyB0byBhbHNvIHByZXNlbnQgYSB2ZXJ5IG5hcnJvdyBleGFtcGxlIG9mDQo+PiB3aGF0 IHRoZSBzaWduYWwgY2hhbm5lbCBtaWdodCBkbyAobGV0IGFsb25lIHRoZSBkYXRhIGNoYW5uZWwp LiAgSSdtIG5vdCBzdXJlDQo+PiBob3cgbXVjaCB0aGlzIHNlbnRlbmNlIGFkZHMgdG8gY2xhcmlm eWluZyB0aGUgc2NvcGUgYXMgc3VnZ2VzdGVkIGJ5IHRoZQ0KPj4gc2VjdGlvbiB0aXRsZS4NCj4g DQo+IEFncmVlZCwgSSBkb24ndCBzZWUgYSBuZWVkIGZvciB0aGlzIHNlbnRlbmNlIGluIHRoZSAi U2NvcGUiIHNlY3Rpb24uIFJlbW92ZWQgaXQuIA0KPiANCj4+IA0KPj4gKiogU2VjdGlvbi4gIDEu MyBQZXIgIlRoZSBzaWduYWwgYW5kIGRhdGEgY2hhbm5lbHMgYXJlIGxvb3NlbHkgY291cGxlZCwg YW5kDQo+PiBtYXkgbm90IHRlcm1pbmF0ZSBvbiB0aGUgc2FtZSBET1RTIHNlcnZlciIsIGl0IHNl ZW1zIGhlbHAgdG8gY2xhcmlmeSB0aGUNCj4+IG9idmlvdXMgdGhhdCBob3cgdGhlc2Ugc2lnbmFs cyB3b3VsZCBiZSBzeW5jaHJvbml6ZWQgaXMgb3V0IG9mIHNjb3BlLg0KPiANCj4gT2theSwgYWRk ZWQgdGhlIGZvbGxvd2luZyBsaW5lOg0KPiBIb3cgdGhlIERPVFMgc2VydmVycyBzeW5jaHJvbml6 ZSB0aGUgRE9UUyBjb25maWd1cmF0aW9uIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIHNwZWNpZmlj YXRpb24uDQo+IA0KPj4gDQo+PiAqKiBTZWN0aW9uIDIuICBGaWd1cmUgMy4gIElzIHRoaXMgZmln dXJlIChpLmUuLCB0aGUgSlNPTiBleGFtcGxlKSBub3JtYXRpdmU/DQo+IA0KPiBOby4NCj4gDQo+ IFRoaXMNCj4+IHNlZW1zIGxpa2UgYSBkZXRhaWwgYmVzdCBsZWZ0IHRvIHRoZSBkYXRhIGNoYW5u ZWwgc3BlYyAoYW5kIG9taXR0ZWQgZnJvbSB0aGlzDQo+PiBkb2N1bWVudCkuDQo+IA0KPiBZZXMs IHdlIGhhdmUgYW4gZXhhbXBsZSBpbiB0aGUgZGF0YSBjaGFubmVsIHNwZWMuIFJlbW92ZWQgRmln dXJlIDMuIA0KPiANCj4+IA0KPj4gKiogU2VjdGlvbiAyLiAgUGVyOg0KPj4gTm90ZSB0aGF0IHdo aWxlIGl0IGlzIHBvc3NpYmxlIHRvIGV4Y2hhbmdlIHRoZSBhYm92ZSBpbmZvcm1hdGlvbg0KPj4g ICBiZWZvcmUsIGR1cmluZyBvciBhZnRlciBhIEREb1MgYXR0YWNrLCBET1RTIHJlcXVpcmVzIHJl bGlhYmxlDQo+PiAgIGRlbGl2ZXJ5IG9mIHRoaXMgaW5mb3JtYXRpb24gYW5kIGRvZXMgbm90IHBy b3ZpZGUgYW55IHNwZWNpYWwgbWVhbnMNCj4+ICAgZm9yIGVuc3VyaW5nIHRpbWVseSBkZWxpdmVy eSBvZiBpdCBkdXJpbmcgYW4gYXR0YWNrLiAgSW4gcHJhY3RpY2UsDQo+PiAgIHRoaXMgbWVhbnMg dGhhdCBET1RTIGRlcGxveW1lbnRzIHNob3VsZCBub3QgcmVseSBvbiBzdWNoIGluZm9ybWF0aW9u DQo+PiAgIGJlaW5nIGV4Y2hhbmdlZCBkdXJpbmcgYSBERG9TIGF0dGFjay4NCj4+IA0KPj4gSXQg c2VlbXMgdG8gbWUgdGhhdCB0aGVyZSBpcyBndWlkYW5jZSBtaXNzaW5nIGhlcmUuICBJZiB0aGUg Zmlyc3Qgc2VudGVuY2Ugc2F5cw0KPj4gdGhhdCB0aGlzIGluZm9ybWF0aW9uIGNhbiBiZSBleGNo YW5nZWQgYmVmb3JlLCBkdXJpbmcgb3IgYWZ0ZXIgYW4gYXR0YWNrLCBidXQNCj4+IGRvbid0IGNv dW50IG9uIGl0IGR1cmluZyB0aGUgYXR0YWNrLiAgVGhlIHNlY29uZCBzZW50ZW5jZSByZWl0ZXJh dGVzIHRoZSBwb2ludA0KPj4gdGhhdCBkdXJpbmcgYW4gYXR0YWNrIGl0IHdpbGwgYmUgdW5yZWxp YWJsZSwgaXMgYSBzdGF0ZW1lbnQgdG8gdGhlIGVmZmVjdCB0aGF0DQo+PiBuZWNlc3NhcnkgY29u ZmlndXJhdGlvbiBtdXN0IGJlIG1hZGUgcHJpb3IgdG8gdGhlIGF0dGFjayBhbHNvIG5lZWRlZD8N Cj4gDQo+IFllcywgdXBkYXRlZCBsYXN0IGxpbmUgYXMgZm9sbG93czoNCj4gSW4gcHJhY3RpY2Us IHRoaXMgbWVhbnMgdGhhdCBET1RTIGRlcGxveW1lbnRzIHNob3VsZCByZWx5IG9uIHN1Y2ggaW5m b3JtYXRpb24gDQo+IGJlaW5nIGV4Y2hhbmdlZCBvbmx5IHVuZGVyIG5vcm1hbCB0cmFmZmljIGNv bmRpdGlvbnMuDQo+IA0KPj4gDQo+PiAqKiBTZWN0aW9uIDIuMSAgUGVyICJJdCBpcyBub3QgdW50 aWwgdGhpcyBwb2ludCB0aGF0IHRoZSBtaXRpZ2F0aW9uIHNlcnZpY2UgaXMNCj4+IGF2YWlsYWJs ZSBmb3IgdXNlLiIsIHRoaXMgY2xvc2luZyBwb2ludCBhYm91dCBhIG1pdGlnYXRpb24gc2Vydmlj ZSBmb2xsb3dzIGZyb20NCj4+IHRoZSBwcmV2aW91cyBkZXNjcmlwdGlvbi4gIEhvd2V2ZXIsIEkg d2FudGVkIHRvIHBvaW50IG91dCwgdGhlIG5vdGlvbiBvZiBhDQo+PiAibWl0aWdhdGlvbiBzZXJ2 aWNlIiBiZWluZyBhdmFpbGFibGUgYWZ0ZXIgYSBmdWxseSBjb25maWd1cmVkIERPVFMgY2xpZW50 IGlzIG5vdA0KPj4gYSBjb25zdHJ1Y3QgcHJldmlvdXNseSB1c2VkIGluIHRoZSBkb2N1bWVudCBv ciB0aGUgdGVybWlub2xvZ3kuICBJdCdzIGxpa2VseQ0KPj4gd29ydGggcmVsYXRpbmcgaXQgdG8g dGhlIHByZXZpb3VzbHkgZGVmaW5lZCB0ZXJtcyBsaWtlIG1pdGlnYXRvci4NCj4gDQo+ICJtaXRp Z2F0aW9uIHNlcnZpY2UiIGlzIGFscmVhZHkgdXNlZCBpbiBTZWN0aW9ucyAyIGFuZCAxLjINCj4g DQo+PiANCj4+ICoqIFNlY3Rpb24gMi4xLiAgVG8gYXZvaWQgY29uZnVzaW9uIG9uIHRlcm1zIChp LmUuLCBmcm9tIEhUVFApLCBwZXJoYXBzDQo+PiByZXBsYWNlIHMvYmFzaWMgYXV0aG9yaXphdGlv bi9hdXRob3JpemF0aW9uLy4NCj4gDQo+IE9rYXksIHJlcGxhY2VkLg0KPiANCj4+IA0KPj4gKiog U2VjdGlvbiAyLjIuMi4gIFBlciAiRm9yIGEgZ2l2ZW4gRE9UUyBjbGllbnQgKGFkbWluaXN0cmF0 aXZlKSBkb21haW4sIHRoZQ0KPj4gRE9UUyBzZXJ2ZXIgbmVlZHMgdG8gYmUgYWJsZSB0byBkZXRl cm1pbmUgd2hldGhlciBhIGdpdmVuIHRhcmdldCAgcmVzb3VyY2UNCj4+IGlzIGluIHRoYXQgZG9t YWluLiIsIHdoYXQgaXMgYSAidGFyZ2V0IHJlc291cmNlIiBpc24ndCBjbGVhci4gIEkgdGhpbmsg aXQgaXMgbWVhbnQgdG8NCj4+IGJlIHRoZSByZXNvdXJjZSB0aGF0IGlzIHRoZSB0YXJnZXQgb2Yg dGhlIGF0dGFjayAodGhhdCB0aGUgRE9UUyBjbGllbnQgaXMNCj4+IHNpZ25hbGluZyBhYm91dCku IA0KPiANCj4gWWVzLg0KPiANCj4+IEFsc28sIHRoZSBpZGVhIHRoYXQgRE9UUyBjbGllbnRzIGhh dmUgImRvbWFpbnMiIGlzIGEgbmV3DQo+PiBjb25jZXB0IGhlcmUgdGhhdCBuZWVkcyBjbGFyaWZp Y2F0aW9uLg0KPiANCj4gSSBoYXZlIHNpbXBsaWZpZWQgdGhlIHRleHQgYXMgZm9sbG93czoNCj4g Rm9yIGEgZ2l2ZW4gRE9UUyBjbGllbnQgKGFkbWluaXN0cmF0aXZlKSBkb21haW4sIHRoZSBET1RT IHNlcnZlciBuZWVkcyB0byBiZQ0KPiBhYmxlIHRvIGRldGVybWluZSB3aGV0aGVyIGEgZ2l2ZW4g cmVzb3VyY2UgaXMgaW4gdGhhdCBkb21haW4uIEZvcg0KPiBleGFtcGxlLCB0aGlzIGNvdWxkIHRh a2UgdGhlIGZvcm0gb2YgYXNzb2NpYXRpbmcgYSBzZXQgb2YgSVAgYWRkcmVzc2VzIGFuZC9vcg0K PiBwcmVmaXhlcyBwZXIgRE9UUyBjbGllbnQgZG9tYWluLg0KPiANCj4+IA0KPj4gKiogU2VjdGlv biAyLjIuMi4gUGVyICJUaGUgRE9UUyBzZXJ2ZXIgZW5mb3JjZXMgYXV0aG9yaXphdGlvbiBvZiBE T1RTDQo+PiBjbGllbnRzJyBzaWduYWxzIGZvciBtaXRpZ2F0aW9uLiIsIG5vIG9iamVjdGlvbi4g IElzIHRoZXJlIGEgY29tcGxlbWVudGFyeQ0KPj4gc3RhdGVtZW50IHRvIG1ha2UgdGhlIGRhdGEg Y2hhbm5lbD8NCj4gDQo+IEdvb2QgcG9pbnQsIHVwZGF0ZWQgdGV4dCBhcyBmb2xsb3dzOg0KPiBU aGUgRE9UUyBzZXJ2ZXIgZW5mb3JjZXMgYXV0aG9yaXphdGlvbiBvZiBzaWduYWxzIGZvciBtaXRp Z2F0aW9uLCBmaWx0ZXJpbmcgcnVsZXMgYW5kIGFsaWFzZXMgZm9yIHJlc291cmNlcyBmcm9tIERP VFMgY2xpZW50cy4gIA0KPiBUaGUgbWVjaGFuaXNtIG9mIGVuZm9yY2VtZW50IGlzIG5vdCBpbiBz Y29wZSBmb3IgdGhpcyBkb2N1bWVudCwgYnV0IGlzIGV4cGVjdGVkIHRvIHJlc3RyaWN0IG1pdGln YXRpb24gcmVxdWVzdHMsIGZpbHRlcmluZyBydWxlcyBhbmQgYWxpYXNlcw0KPiBzY29wZSB0byBh ZGRyZXNzZXMsIHByZWZpeGVzLCBhbmQvb3Igc2VydmljZXMgb3duZWQgYnkgdGhlIERPVFMgY2xp ZW50IGRvbWFpbiwgc3VjaCB0aGF0IGEgRE9UUw0KPiBjbGllbnQgZnJvbSBvbmUgZG9tYWluIGlz IG5vdCBhYmxlIHRvIGluZmx1ZW5jZSB0aGUgbmV0d29yayBwYXRoIHRvIGFub3RoZXINCj4gZG9t YWluLiBBIERPVFMgc2VydmVyIE1VU1QgcmVqZWN0IHJlcXVlc3RzIGZvciBtaXRpZ2F0aW9uIG9m IHJlc291cmNlcywgZmlsdGVyaW5nIHJ1bGVzIGFuZCBhbGlhc2VzIGZvcg0KPiByZXNvdXJjZXMg bm90IG93bmVkIGJ5IHRoZSByZXF1ZXN0aW5nIERPVFMgY2xpZW50J3MgYWRtaW5pc3RyYXRpdmUg ZG9tYWluLg0KPiANCj4+IA0KPj4gKiogU2VjdGlvbiA1LiAgUGVyICJBbnkgYXR0YWNrZXIgd2l0 aCB0aGUgYWJpbGl0eSB0byBpbXBlcnNvbmF0ZSAuLi4iLCB0aGlzDQo+PiBwYXJhZ3JhcGggY2xl YXJseSBkZXNjcmliZXMgaW4gdGhlIGltcGFjdCBvZiBpbXBlcnNvbmF0aW9uLiAgSG93ZXZlciwg dGhlDQo+PiBzdWdnZXN0ZWQgbWl0aWdhdGlvbnMgcmVhZCBsaWtlIHJlcXVpcmVtZW50cy4gIElu c3RlYWQgb2YgdHJ5aW5nIHRvIGxpc3QgdGhlbQ0KPj4gYWdhaW4sIEkgd291bGQgcmVjb21tZW5k IGV4cGxpY2l0bHkgY2l0aW5nIHRoZSByZWxldmFudCByZXF1aXJlbWVudHMgZnJvbQ0KPj4gU2Vj dGlvbiAyLjQgb2YgdGhlIFJGQzg2MTIgYW5kIG5vdGluZyB0aGF0IG5lZWQgZm9yIGNvbmZvcm1h bmNlIHRvIHRoZXNlDQo+PiBzZWN1cml0eSBtZWNoYW5pc21zLg0KPiANCj4gR29vZCBwb2ludCwg dXBkYXRlZCBwYXJhZ3JhcGggYXMgZm9sbG93czoNCj4gDQo+IEFueSBhdHRhY2tlciB3aXRoIHRo ZSBhYmlsaXR5IHRvIGltcGVyc29uYXRlIGEgbGVnaXRpbWF0ZSBET1RTIGNsaWVudCBvciBzZXJ2 ZXINCj4gb3IsIGluZGVlZCwgaW5qZWN0IGZhbHNlIG1lc3NhZ2VzIGludG8gdGhlIHN0cmVhbSBt YXkgcG90ZW50aWFsbHkNCj4gdHJpZ2dlci93aXRoZHJhdyB0cmFmZmljIHJlZGlyZWN0aW9uLCB0 cmlnZ2VyL2NhbmNlbCBtaXRpZ2F0aW9uIGFjdGl2aXRpZXMgb3INCj4gc3VidmVydCBkcm9wLS9h Y2NlcHQtbGlzdHMuICBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludCwgb3BlcmF0b3Jz IE1VU1QNCj4gZW5zdXJlIGNvbmZvcm1hbmNlIHRvIHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMg ZGVmaW5lZCBpbiBTZWN0aW9uIDIuNCBvZiANCj4gUkZDODYxMiB0byBzZWN1cmUgZGF0YSBpbiB0 cmFuc2l0LiANCj4gDQo+PiANCj4+ICoqIFNlY3Rpb24gNS4gIFBlciAiU2ltaWxhcmx5LCByZWNl aXZlZCBkYXRhIGF0IHJlc3QgU0hPVUxEIGJlIHN0b3JlZCB3aXRoIGENCj4+IHNhdGlzZmFjdG9y eSBkZWdyZWUgb2Ygc2VjdXJpdHkuIiwgSSB3b3VsZCByZWNvbW1lbmQgZXhwbGFpbmluZyB3aHkg dGhlDQo+PiBkYXRhIHNob3VsZCBiZSBzZWN1cmVkLiBQZXJoYXBzOg0KPj4gT0xEOg0KPj4gU2lt aWxhcmx5LCByZWNlaXZlZCBkYXRhIGF0IHJlc3QgU0hPVUxEIGJlDQo+PiAgIHN0b3JlZCB3aXRo IGEgc2F0aXNmYWN0b3J5IGRlZ3JlZSBvZiBzZWN1cml0eS4NCj4+IA0KPj4gTkVXIChvciBzb21l dGhpbmcgbGlrZSBpdCk6DQo+PiBTaW1pbGFybHksIGFzIHRoZSByZWNlaXZlZCBkYXRhIG1heSBj b250YWluIG5ldHdvcmsgdG9wb2xvZ3ksIHRlbGVtZXRyeSwNCj4+IHRocmVhdCwgb3IgcHJlY29u ZmlndXJlZCBtaXRpZ2F0aW9uIGluZm9ybWF0aW9uIHdoaWNoIGNvdWxkIGJlIGNvbnNpZGVyZWQN Cj4+IHNlbnNpdGl2ZSBpbiBjZXJ0YWluIGVudmlyb25tZW50LCBpdCBTSE9VTEQgYmUgcHJvdGVj dGVkIGF0IHJlc3QgcGVyIHJlcXVpcmVkDQo+PiBsb2NhbCBwb2xpY3kuDQo+IA0KPiBXb3JrcyBm b3IgbWUsIG1pbm9yIHVwZGF0ZSB0byBwcm9wb3NlZCB0ZXh0Og0KPiANCj4gU2ltaWxhcmx5LCBh cyB0aGUgcmVjZWl2ZWQgZGF0YSBtYXkgY29udGFpbiBuZXR3b3JrIHRvcG9sb2d5LCB0ZWxlbWV0 cnksDQo+IHRocmVhdCBhbmQgbWl0aWdhdGlvbiBpbmZvcm1hdGlvbiB3aGljaCBjb3VsZCBiZSBj b25zaWRlcmVkDQo+IHNlbnNpdGl2ZSBpbiBjZXJ0YWluIGVudmlyb25tZW50LCBpdCBTSE9VTEQg YmUgcHJvdGVjdGVkIGF0IHJlc3QgcGVyIHJlcXVpcmVkDQo+IGxvY2FsIHBvbGljeS4NCj4gDQo+ PiANCj4+ICoqIFNlY3Rpb24gNS4gIFBlciAiQXMgbWFueSBtaXRpZ2F0aW9uIHN5c3RlbXMgZW1w bG95IGRpdmVyc2lvbiB0byBzY3J1Yg0KPj4gYXR0YWNrIHRyYWZmaWMsIG9wZXJhdG9ycyBvZiBE T1RTIGFnZW50cyBTSE9VTEQgZW5zdXJlIERPVFMgc2Vzc2lvbnMgYXJlDQo+PiByZXNpc3RhbnQg dG8gTWFuLWluLXRoZS1NaWRkbGUgKE1pdE0pIGF0dGFja3MuIiwgSSdtIG5vdCBmb2xsb3dpbmcg dGhlIGxpbmsNCj4+IGJldHdlZW4gdGhlIG1pdGlnYXRpb24gc3lzdGVtcyByZS1yb3V0aW5nIHRy YWZmaWMgd2l0aCBET1RTIGFnZW50cyByZXNpc3RpbmcNCj4+IE1pdE0gYXR0YWNrLiAgV2hhdCBh Y3Rpb25zIHNob3VsZCBiZSBhZ2VudHMgYmUgdGFraW5nPw0KPiANCj4gR29vZCBwb2ludCwgbW9k aWZpZWQgcGFyYWdyYXBoIGFzIGZvbGxvd3MgKGFuZCByZW1vdmVkIGxpbmUgZGlzY3Vzc2luZyBy ZS1yb3V0aW5nIHRyYWZmaWMpOg0KPiANCj4gQW4gYXR0YWNrZXIgd2l0aCBjb250cm9sIG9mIGEg RE9UUyBjbGllbnQgbWF5IG5lZ2F0aXZlbHkNCj4gaW5mbHVlbmNlIG5ldHdvcmsgdHJhZmZpYyBi eSByZXF1ZXN0aW5nIGFuZCB3aXRoZHJhd2luZyByZXF1ZXN0cyBmb3IgbWl0aWdhdGlvbg0KPiBm b3IgcGFydGljdWxhciBwcmVmaXhlcywgbGVhZGluZyB0byByb3V0ZSBvciBETlMgZmxhcHBpbmcu IERPVFMgb3BlcmF0b3JzIHNob3VsZCBjYXJlZnVsbHkNCj4gbW9uaXRvciBhbmQgYXVkaXQgRE9U UyBjbGllbnRzIHRvIGRldGVjdCBtaXNiZWhhdmlvciBhbmQgZGV0ZXIgbWlzdXNlLg0KPiANCj4g DQo+PiANCj4+ICoqIFNlY3Rpb24gNS4gIFBlcjoNCj4+ICAgQW55IGF0dGFjayB0YXJnZXRpbmcg dGhlIGF2YWlsYWJpbGl0eSBvZiBET1RTIHNlcnZlcnMgbWF5IGRpc3J1cHQgdGhlDQo+PiAgIGFi aWxpdHkgb2YgdGhlIHN5c3RlbSB0byByZWNlaXZlIGFuZCBwcm9jZXNzIERPVFMgc2lnbmFscyBy ZXN1bHRpbmcNCj4+ICAgaW4gZmFpbHVyZSB0byBmdWxmaWxsIGEgbWl0aWdhdGlvbiByZXF1ZXN0 LiAgRE9UUyBhZ2VudHMgU0hPVUxEIGJlDQo+PiAgIGdpdmVuIGFkZXF1YXRlIHByb3RlY3Rpb25z LCBhZ2FpbiBpbiBhY2NvcmRhbmNlIHdpdGggYmVzdCBjdXJyZW50DQo+PiAgIHByYWN0aWNlcyBm b3IgbmV0d29yayBhbmQgaG9zdCBzZWN1cml0eS4NCj4+IC0tIFRoZSBmaXJzdCBzZW50ZW5jZSB0 YWxrcyBhYm91dCAiRE9UUyBzZXJ2ZXJzIi4gIFRoZSBzZWNvbmQgdGFsayBhYm91dA0KPj4gcHJv dGVjdGluZyAiRE9UUyBhZ2VudHMiLiAgV2hhdCdzIHRoZSByb2xlIGluIHRoZSBET1RTIGNsaWVu dHMgaW4gdGhpcw0KPj4gZ3VpZGFuY2U/DQo+PiAtLSBTaG91bGRuJ3QgdGhlIHByb3RlY3Rpb25z IGFmZm9yZGVkIHRvIHRoZSBET1RTIGFnZW50cyBiZSBhIG1hbmRhdG9yeQ0KPj4gKE1VU1QpPw0K PiANCj4gR29vZCBwb2ludCwgdGhlIGd1aWRhbmNlIGlzIG9ubHkgbWVhbnQgZm9yIERPVFMgc2Vy dmVycyBhbmQgaXMgbWFuZGF0b3J5LiBNb2RpZmllZCB0ZXh0IGFzIGZvbGxvd3M6DQo+IERPVFMg c2VydmVycyBNVVNUIGJlIGdpdmVuIGFkZXF1YXRlIHByb3RlY3Rpb25zLCAgaW4gYWNjb3JkYW5j ZSB3aXRoIGJlc3QgY3VycmVudCBwcmFjdGljZXMgZm9yIG5ldHdvcmsgYW5kIGhvc3Qgc2VjdXJp dHkuDQo+IA0KPj4gDQo+PiAqKiBFZGl0b3JpYWwgTml0czoNCj4+IC0tIFNlY3Rpb24gMS4gIEVk aXRvcmlhbC4gcy9mb3IgaGVscCBkZWZlbmRpbmcvZm9yIGhlbHAgdG8gZGVmZW5kLw0KPj4gLS0g U2VjdGlvbiAzLjIuNS4gIFR5cG8uIHMvZGVwbG95ZW1lbnRzL2RlcGxveW1lbnRzLw0KPiANCj4g VGhhbmtzLCBGaXhlZC4NCj4gDQo+IENoZWVycywNCj4gLVRpcnUNCj4gDQo+PiANCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBEb3RzIG1haWxp bmcgbGlzdA0KPj4gRG90c0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kb3RzDQo+IA0K From nobody Fri Jan 10 22:21: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 52D86120128 for ; Fri, 10 Jan 2020 22:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgL_q3EBNS3B for ; Fri, 10 Jan 2020 22:21:13 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C19120127 for ; Fri, 10 Jan 2020 22:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578723672; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XFSyIgZ+GGdEzVxbN9RL3dtqqKW2H5K3q3Dfb5a8fm0=; b=JMQ+tnA4thDSRL7yubGtYx0uXZFLNx7q+AuVvi70qc4oI15WyV/NgzkIitepakeUIzPmaK xFfMSADmdTdVO+uHjyNPbtd1neMP78mOKnpGBItfOZAL3McW+SL6ELlLQxY3MqLwiHLEOm 8zsPVQedCWTmL1ixhslJPKtkIGOy75A= Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-305-OPkEOxCMODKGQG2oZ156qw-1; Sat, 11 Jan 2020 01:21:10 -0500 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1178.namprd16.prod.outlook.com (10.172.85.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Sat, 11 Jan 2020 06:21:09 +0000 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4%3]) with mapi id 15.20.2623.013; Sat, 11 Jan 2020 06:21:09 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Roman Danyliw , "dots@ietf.org" Thread-Topic: AD Review of draft-ietf-dots-architecture-14 Thread-Index: AdXHMmoiRx3D3KUrRUiecOSiRVyATgAQ2HbAAAi9PtAAK44p4A== Date: Sat, 11 Jan 2020 06:21:09 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01E7100170@marchand> <787AE7BB302AE849A7480A190F8B9330314072F3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314072F3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5543fa5-6a7c-46b6-363e-08d7965e72c4 x-ms-traffictypediagnostic: DM5PR1601MB1178: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2733; x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(346002)(396003)(376002)(189003)(199004)(32952001)(52536014)(33656002)(5660300002)(86362001)(53546011)(6506007)(186003)(478600001)(55016002)(316002)(26005)(8936002)(9686003)(110136005)(66446008)(66556008)(66946007)(64756008)(7696005)(76116006)(66476007)(8676002)(81166006)(2906002)(81156014)(71200400001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1178; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9nDSTmajhsNRkG56FVfPhreJxQefUz5BhKdpERoMXJczccwYhHKy14Oh3+T91Zd2rujYanQKmZZswnCiETRhF4j1oy+L2R6y+EWxyhEs1tGyQwgqPqn5abCmtDOhj2gW55I0OD0fhSrax1ylaQogOVTAUJNwqPbLFZfyVIGgAU9AGFCgH1858yHgIDF6+srmNsOUyGWsv+7qsobXbSWkiB3ckvtQVmhPx9I7fgaK7xEAyf6S0ngZsR+8zeLHbSoiI8Yn/JDPH3Sceifq58MjuG+AQu0VjKInsgRK7fa2LsYB3ono0BdDCEhck2SlTpUUQLz8aAF6Vnq0Zj/R1IQIt3ZmCmRe5j9ogDnfmh6kwag6WReCFjpS4H7HIdebEZVQlR5bTQdVoywFXrswtjF8KwLCmJ6F3NGTyBD9+bG3uo3cNC9TE6uqKJIfgYLQoJB36D2cA0jjy/pjmFpcui8IwfidRHe34w0SuMcZJ6+3zOMaywigvDJggWMzWTcDxqiDQrdRwM1Gz/SUAdcV9SipPA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5543fa5-6a7c-46b6-363e-08d7965e72c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2020 06:21:09.1738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zrwoL4KKJdMYrCOq2p8uGsT2mAzjXDSx+x0CQBMK/kidRYDWM3HXRv/A69+Jx8st3UMsb2c1dSV7PSDK6dWE3kTLFhsBU++NVx6L3MSz6FBPhxJkjCEggVvHVbcKNRlh X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1178 X-MC-Unique: OPkEOxCMODKGQG2oZ156qw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] AD Review of draft-ietf-dots-architecture-14 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 06:21:16 -0000 Thanks Med, will update text. Cheers, -Tiru > -----Original Message----- > From: mohamed.boucadair@orange.com > > Sent: Friday, January 10, 2020 3:19 PM > To: Konda, Tirumaleswar Reddy > ; Roman Danyliw > ; dots@ietf.org > Subject: RE: AD Review of draft-ietf-dots-architecture-14 >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Hi Tiru, all, >=20 > Two minor comments inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: vendredi 10 janvier 2020 10:05 =C0=A0: = Roman > > Danyliw; dots@ietf.org Objet=A0: Re: [Dots] AD Review of > > draft-ietf-dots-architecture-14 > > > > Hi Roman, > > > > Thanks for the review. Please see inline > > > > > -----Original Message----- > > > From: Dots On Behalf Of Roman Danyliw > > > Sent: Friday, January 10, 2020 3:00 AM > > > To: dots@ietf.org > > > Subject: [Dots] AD Review of draft-ietf-dots-architecture-14 > > > > > > CAUTION: External email. Do not click links or open attachments > > > unless > > you > > > recognize the sender and know the content is safe. > > > > > > Hello! > > > > > > The following is my AD review of draft-ietf-dots-architecture-14: > ... > > > > > > ** Section 2.1 Per "It is not until this point that the mitigation > > service is > > > available for use.", this closing point about a mitigation service > > follows from > > > the previous description. However, I wanted to point out, the > > > notion > > of a > > > "mitigation service" being available after a fully configured DOTS > > client is not > > > a construct previously used in the document or the terminology. > > > It's > > likely > > > worth relating it to the previously defined terms like mitigator. > > > > "mitigation service" is already used in Sections 2 and 1.2 >=20 > [Med] Given that only "mitigation" and "mitigator" are defined in the > terminology inherited from RFC8612, I suggest to make this simple change: >=20 > OLD: > A simple example instantiation of the DOTS architecture could be an > enterprise as the attack target for a volumetric DDoS attack, and an > upstream DDoS mitigation service as the mitigator. >=20 > NEW: > A simple example instantiation of the DOTS architecture could be an > enterprise as the attack target for a volumetric DDoS attack, and an > upstream DDoS mitigator. The service provided by the mitigator is call= ed: > DDoS mitigation service. >=20 > > > > > > > > ** Section 2.1. To avoid confusion on terms (i.e., from HTTP), > > perhaps > > > replace s/basic authorization/authorization/. > > > > Okay, replaced. > > > > > > > > ** Section 2.2.2. Per "For a given DOTS client (administrative) > > domain, the > > > DOTS server needs to be able to determine whether a given target > > resource > > > is in that domain.", what is a "target resource" isn't clear. I > > > think > > it is meant to > > > be the resource that is the target of the attack (that the DOTS > > > client > > is > > > signaling about). > > > > Yes. > > > > > Also, the idea that DOTS clients have "domains" is a new concept > > > here that needs clarification. > > > > I have simplified the text as follows: > > For a given DOTS client (administrative) domain, the DOTS server needs > > to be able to determine whether a given resource is in that domain. > > For example, this could take the form of associating a set of IP > > addresses and/or prefixes per DOTS client domain. >=20 > [Med] Please make sure that the same wording is consistently used in the > document. Typically, please make these changes in many places of the > document: >=20 > s/DOTS client's domain/DOTS client domain s/DOTS server's domain/DOTS > server domain >=20 > This is also to be aligned with the signal channel document. Thanks. From nobody Fri Jan 10 22:23: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 3D867120128; Fri, 10 Jan 2020 22:23:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <157872383214.13198.9296765109429148842@ietfa.amsl.com> Date: Fri, 10 Jan 2020 22:23:52 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-15.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: Sat, 11 Jan 2020 06:23: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) Architecture Authors : Andrew Mortensen Tirumaleswar Reddy Flemming Andreasen Nik Teague Rich Compton Filename : draft-ietf-dots-architecture-15.txt Pages : 33 Date : 2020-01-10 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-15 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-15 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 Fri Jan 10 22:24: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 4D782120128 for ; Fri, 10 Jan 2020 22:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL0v_9snJpqA for ; Fri, 10 Jan 2020 22:24:56 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B140112004F for ; Fri, 10 Jan 2020 22:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578723895; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5/ssmppryTQTm5O6NRJDYjtuQiykV8qhHMcUH8xQ9Qw=; b=k8ljIA2vWr4TQ+RwoKuCg3L4qhB+NfbNvM5cGEJ3pdvcWvZSwJRoKSIg4+NksNI6cEY4Xr sOD+phhGANGwZgMiokkoFDntu7l0pF4YUd+56z0Lu2rCRY7ig/cqNyOGCZ5IefQTK/MQUq rCl4O+1APud/u9CSFSnxzup3wrs+qNQ= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-287-AV9pTIsnNre6xS8UYherjg-1; Sat, 11 Jan 2020 01:24:53 -0500 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1274.namprd16.prod.outlook.com (10.172.87.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Sat, 11 Jan 2020 06:24:52 +0000 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4%3]) with mapi id 15.20.2623.013; Sat, 11 Jan 2020 06:24:52 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" , Roman Danyliw Thread-Topic: [Dots] I-D Action: draft-ietf-dots-architecture-15.txt Thread-Index: AQHVyEe6yhh2ggJjC0SuEfpi1HQ1R6fk/wFQ Date: Sat, 11 Jan 2020 06:24:52 +0000 Message-ID: References: <157872383214.13198.9296765109429148842@ietfa.amsl.com> In-Reply-To: <157872383214.13198.9296765109429148842@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 652b87ed-eb95-4cc8-e563-08d7965ef7c5 x-ms-traffictypediagnostic: DM5PR1601MB1274: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(199004)(189003)(32952001)(66556008)(66446008)(316002)(66574012)(64756008)(66476007)(5660300002)(52536014)(110136005)(33656002)(8936002)(86362001)(478600001)(71200400001)(2906002)(26005)(81156014)(8676002)(55016002)(81166006)(9686003)(7696005)(76116006)(186003)(966005)(66946007)(6506007)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1274; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WGGO/Vkdz0LaLXINFnsvjzAP8MRUA6PdpqEkxPk9wKLcSomgEjasGhN2g7CKDP+i3SSjPivNHRUu4AUXF2v6aiH001v+vxtv1FQSsCL8bmBqi2l6vY3UwI+4kGxX6Y2/8Xvoo4GL6jsLq0NDXOhg8f0BaJxoNZFTsa5YmDjkljOsfRxB/deR4EygQ6N0rZJVG30+4FVkd+tJ+BvEbEZ/GQNWOcV2IsBVub+a82d/o2Rbr5V+LR7511S+gzODnF0sEy1wfv6lz9jQP0oua4zfzZPerhef1yVPcgpDRw1bUVWlXv8ZGkulgll9Ntfe4myA3r/5Yfuetf7LdAy1RZl+a5qttXtHRRytsP5o/pxwSl9QEbdHOaT6bF/efg4BbAR0C1XDdpAr+ufs3dHAWWA0xWlDVRHURz54ZaIjyLvCt/ltsh8tSDbgBGnh98iu9SEdVY20Kt3ZG8LEf5skiOQnAZrmKn6dcPlZKnP2RbKPV7K1JPIJBubQjZuVQrE9LwyaiC6+nF05xIcNKPEVMvqOjdjHFCk0DwOnzqe25Ep0clB8vuR59GSFWmN6bdBW0ylXTF9t1p2/lHukVdiL4MmKXxf0Ng/wddIcUkDKCS3kphs= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 652b87ed-eb95-4cc8-e563-08d7965ef7c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2020 06:24:52.3478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5BsyzexQ841OKn/WKKcjrXKRHThLTqgTkfWWcAXs+DO71b7EU64/xcRbX0w9TXk5BzlNE35ebf2tTLmmBMHBpwQRy1a0YM4N5t0GNKL0NrTILs85M2qZUC4gR+bkV+lB X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1274 X-MC-Unique: AV9pTIsnNre6xS8UYherjg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-architecture-15.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 06:24:58 -0000 This revision addresses comments from Roman and Med. -Tiru > -----Original Message----- > From: Dots On Behalf Of internet-drafts@ietf.org > Sent: Saturday, January 11, 2020 11:54 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-architecture-15.txt >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed-Denial-of-Service Open Threat Signa= ling (DOTS) > Architecture > Authors : Andrew Mortensen > Tirumaleswar Reddy > Flemming Andreasen > Nik Teague > Rich Compton > =09Filename : draft-ietf-dots-architecture-15.txt > =09Pages : 33 > =09Date : 2020-01-10 >=20 > Abstract: > This document describes an architecture for establishing and > maintaining Distributed Denial of Service (DDoS) Open Threat > Signaling (DOTS) within and between domains. The document does not > specify protocols or protocol extensions, instead focusing on > defining architectural relationships, components and concepts used in > a DOTS deployment. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-architecture-15 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-15 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Jan 13 14:03:06 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 00D3812001B; Mon, 13 Jan 2020 14:03:05 -0800 (PST) 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: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: rdd@cert.org, valery@smyslov.net, draft-ietf-dots-architecture@ietf.org, dots@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157895298493.32387.3217017837571182348.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2020 14:03:04 -0800 Archived-At: Subject: [Dots] Last Call: (Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture) to Informational RFC 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, 13 Jan 2020 22:03:05 -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) Architecture' as Informational RFC 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-01-27. 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 describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jan 13 23:26:27 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 04ABE12007C; Mon, 13 Jan 2020 23:26:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, iesg-secretary@ietf.org, dots@ietf.org Message-ID: <157898678501.9133.10865101958308084163.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2020 23:26:25 -0800 Archived-At: Subject: [Dots] Publication has been requested for draft-ietf-dots-signal-call-home-07 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, 14 Jan 2020 07:26:25 -0000 Valery Smyslov has requested publication of draft-ietf-dots-signal-call-home-07 as Proposed Standard on behalf of the DOTS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ From nobody Wed Jan 22 01:44:34 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 09C461200D8; Wed, 22 Jan 2020 01:44:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <157968626700.12299.9606343571910642998@ietfa.amsl.com> Date: Wed, 22 Jan 2020 01:44:27 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-multihoming-03.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, 22 Jan 2020 09:44:27 -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 : Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) Authors : Mohamed Boucadair Tirumaleswar Reddy Wei Pan Filename : draft-ietf-dots-multihoming-03.txt Pages : 15 Date : 2020-01-22 Abstract: This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide some guidance for DOTS clients/gateways when multihomed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-multihoming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-multihoming-03 https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-multihoming-03 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 Jan 23 07:41:29 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A5312013B for ; Thu, 23 Jan 2020 07:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4MEilLbvMuot for ; Thu, 23 Jan 2020 07:41:25 -0800 (PST) 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 0616D12007C for ; Thu, 23 Jan 2020 07:41:25 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 483RMR6K29z2y3d; Thu, 23 Jan 2020 16:41:23 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 483RMR5FkFzCqkw; Thu, 23 Jan 2020 16:41:23 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 23 Jan 2020 16:41:23 +0100 From: To: "dots@ietf.org" , 'kaname nishizuka' Thread-Topic: DOTS Telemetry: URI Path Thread-Index: AdXSA4rBzLMvgmnTQFWFKSY1yB+Z8Q== Date: Thu, 23 Jan 2020 15:41:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303140D0DC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303140D0DCOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] DOTS Telemetry: URI Path X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 15:41:27 -0000 --_000_787AE7BB302AE849A7480A190F8B93303140D0DCOPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In the current version of the telemetry draft, we are using '/telemetry' fo= r telemetry-related operations. Kaname suggested to define three operation = suffixes for that. I do think that two are sufficient as indicated below: +-------------------------+----------------+ | Operation | Operation Path | +-------------------------+----------------+ | Telemetry Setup | /tm-setup | +-------------------------+----------------+ | Telemetry | /tm | +-------------------------+----------------+ A dedicated uri (/tm-setup) will be used for telemetry setup operations (ba= seline, configuration): see the excerpt below: augment /ietf-signal:dots-signal/ietf-signal:message-type: +--:(telemetry-setup) {dots-telemetry}? | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 | +--rw telemetry-config | | +--rw low-percentile? percentile | | +--rw mid-percentile? percentile | | +--rw high-percentile? percentile | | +--rw unit-config* [unit] | | +--rw unit unit | | +--rw unit-status? Boolean ... | +--rw baseline | +--rw total-pipe-capability* [unit] | | +--rw unit unit | | +--rw pipe? uint64 | +--rw total-traffic-normal-baseline* [unit protocol] | | +--rw unit unit | | +--rw protocol uint8 | | +--rw low-percentile-g? yang:gauge64 | | +--rw mid-percentile-g? yang:gauge64 | | +--rw high-percentile-g? yang:gauge64 | | +--rw peak-g? yang:gauge64 | +--rw total-connection-capacity* [protocol] | +--rw protocol uint8 ... While '/tm' can be used for sharing pre-mitigation telemetry data (an excer= pt of the tree is shown below). +--:(telemetry) {dots-telemetry}? +--rw pre-mitigation* [cuid telemetry-id] +--rw cuid string +--rw cdid? string +--rw telemetry-id uint32 +--rw target | +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri +--ro total-attack-traffic* [unit protocol] | +--ro unit unit | +--ro protocol uint8 | +--ro low-percentile-g? yang:gauge64 | +--ro mid-percentile-g? yang:gauge64 | +--ro high-percentile-g? yang:gauge64 | +--ro peak-g? yang:gauge64 +--ro total-traffic* [unit protocol] ... +--ro attack-detail +--ro vendor-id? uint32 +--ro attack-id? string +--ro attack-name? string +--ro attack-severity? attack-severity +--ro start-time? uint64 +--ro end-time? uint64 +--ro source-count | +--ro low-percentile-g? yang:gauge64 | +--ro mid-percentile-g? yang:gauge64 | +--ro high-percentile-g? yang:gauge64 | +--ro peak-g? yang:gauge64 +--ro top-talker +--ro source-prefix* [source-prefix] +--ro spoofed-status? boolean +--ro source-prefix inet:ip-prefix ... Unless there are objections, we will implement this change in the next iter= ation of the draft. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93303140D0DCOPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi all,

=  

= In the current version of the telemetry draft, we are using ‘/telemet= ry’ for telemetry-related operations. Kaname suggested to define thre= e operation suffixes for that. I do think that two are sufficient as indicated below:

=  

=          +---------------------= ----+----------------+

=          | Operation  &nb= sp;            | Ope= ration Path |

=          +---------------------= ----+----------------+

=          | Telemetry Setup &nb= sp;       | /tm-setup    =   |

=          +---------------------= ----+----------------+

=          | Telemetry  &nb= sp;            | /tm=             |

=          +---------------------= ----+----------------+

=  

= A dedicated uri (/tm-setup) will be used for telemetry setup operations (ba= seline, configuration): see the excerpt below:

=  

  augment /ietf-signa= l:dots-signal/ietf-signal:message-type:

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

    | = +--rw telemetry* [cuid tsid]

    | =     +--rw cuid       =          string

    | =     +--rw cdid?       = ;        string

    | =     +--rw tsid       =          uint32

    | =     +--rw telemetry-config

    | =     |  +--rw low-percentile?    perc= entile

    | =     |  +--rw mid-percentile?    perc= entile

    | =     |  +--rw high-percentile?   percentil= e

    | =     |  +--rw unit-config* [unit]<= /p>

    | =     |     +--rw unit  &nbs= p;        unit

    | =     |     +--rw unit-status? &n= bsp; Boolean

    &n= bsp;       …

    | =     +--rw baseline

    | =        +--rw total-pipe-capability* [unit= ]

    | =        |  +--rw unit  &nbs= p; unit

    | =        |  +--rw pipe?   ui= nt64

    | =        +--rw total-traffic-normal-baselin= e* [unit protocol]

    | =        |  +--rw unit   &nb= sp;            =  unit

    | =        |  +--rw protocol  =            uint8

    | =        |  +--rw low-percentile-g?&nb= sp;   yang:gauge64

    | =        |  +--rw mid-percentile-g?&nb= sp;   yang:gauge64

    | =        |  +--rw high-percentile-g?&n= bsp;  yang:gauge64

    | =        |  +--rw peak-g?  &= nbsp;           yang:gaug= e64

    | =        +--rw total-connection-capacity* [= protocol]

    | =           +--rw protocol&n= bsp;            = ;        uint8    &n= bsp;

    &n= bsp; …

=  

= While ‘/tm’ can be used for sharing pre-mitigation telemetry da= ta (an excerpt of the tree is shown below).

=  

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

    &n= bsp;  +--rw pre-mitigation* [cuid telemetry-id]<= /p>

    &n= bsp;     +--rw cuid     &n= bsp;            = ;     string

    &n= bsp;     +--rw cdid?     &= nbsp;           &nbs= p;    string

    &n= bsp;     +--rw telemetry-id    =            uint32

    &n= bsp;     +--rw target

    &n= bsp;     |  +--rw target-prefix*  &n= bsp;    inet:ip-prefix

    &n= bsp;     |  +--rw target-port-range* [lower-po= rt]

    &n= bsp;     |  |  +--rw lower-port &nbs= p;  inet:port-number

    &n= bsp;     |  |  +--rw upper-port? &nb= sp; inet:port-number

    &n= bsp;     |  +--rw target-protocol*  =    uint8

    &n= bsp;     |  +--rw target-fqdn*  &nbs= p;      inet:domain-name

    &n= bsp;     |  +--rw target-uri*   = ;       inet:uri

    &n= bsp;     +--ro total-attack-traffic* [unit protocol= ]

    &n= bsp;     |  +--ro unit    =              un= it

    &n= bsp;     |  +--ro protocol   &n= bsp;         uint8

    &n= bsp;     |  +--ro low-percentile-g?  = ;  yang:gauge64

    &n= bsp;     |  +--ro mid-percentile-g?  = ;  yang:gauge64

    &n= bsp;     |  +--ro high-percentile-g? &nbs= p; yang:gauge64

    &n= bsp;     |  +--ro peak-g?   &nb= sp;          yang:gauge64=

    &n= bsp;     +--ro total-traffic* [unit protocol]<= /o:p>

    &n= bsp;     …

    &n= bsp;     +--ro attack-detail

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

    &n= bsp;        +--ro attack-id? &n= bsp;       string

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

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

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

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

    &n= bsp;        +--ro source-count<= /o:p>

    &n= bsp;        |  +--ro low-percen= tile-g?    yang:gauge64

    &n= bsp;        |  +--ro mid-percen= tile-g?    yang:gauge64

    &n= bsp;        |  +--ro high-perce= ntile-g?   yang:gauge64

    &n= bsp;        |  +--ro peak-g?&nb= sp;            = yang:gauge64

    &n= bsp;        +--ro top-talker

    &n= bsp;           +--ro = source-prefix* [source-prefix]

    &n= bsp;            = ;  +--ro spoofed-status?       =      boolean

    &n= bsp;            = ;  +--ro source-prefix       &n= bsp;      inet:ip-prefix

    &n= bsp;           …

=  

= Unless there are objections, we will implement this change in the next iter= ation of the draft.

=  

= Cheers,

= Med

--_000_787AE7BB302AE849A7480A190F8B93303140D0DCOPEXCAUBMA2corp_-- From nobody Sun Jan 26 05:44:15 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E3E12009C; Sun, 26 Jan 2020 05:44:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke via Datatracker To: Cc: last-call@ietf.org, dots@ietf.org, draft-ietf-dots-architecture.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joe Clarke Message-ID: <158004625316.30611.7263339928760109963@ietfa.amsl.com> Date: Sun, 26 Jan 2020 05:44:13 -0800 Archived-At: Subject: [Dots] Opsdir last call review of draft-ietf-dots-architecture-15 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 13:44:13 -0000 Reviewer: Joe Clarke Review result: Ready I have reviewed this draft covering the DOTS architecture on behalf of the ops directorate. I found this draft well-written and ready for progression from an ops perspective. I was especially pleased that it discussed the impact of an active DDoS on the behavior of the client/server interaction and how that might be mitigated or at least better understood. Additionally, the mention of keepalive tuning to avoid _that_ being treated as its own DDoS was appreciated. From nobody Tue Jan 28 22:59: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 235641201E5; Tue, 28 Jan 2020 22:59:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158028115303.4660.5761398190957498256@ietfa.amsl.com> Date: Tue, 28 Jan 2020 22:59:13 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-16.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, 29 Jan 2020 06:59:13 -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) Architecture Authors : Andrew Mortensen Tirumaleswar Reddy Flemming Andreasen Nik Teague Rich Compton Filename : draft-ietf-dots-architecture-16.txt Pages : 35 Date : 2020-01-28 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-16 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-16 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 Jan 28 23:03: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 3E3BF1201E5 for ; Tue, 28 Jan 2020 23:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWfpiq_gJXnv for ; Tue, 28 Jan 2020 23:03:47 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1F61201DB for ; Tue, 28 Jan 2020 23:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580281426; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZRDtsCg27qh/bMcTDGxyIBm2c9bCDvSqDiXolp5hQgw=; b=TwI+rv3Wt9M+6HH3X2N6JnchW8TcBabx53QCg7ZJv5u0uadqIlxeInbf6XxJIQVBVAEu3L 6KUCYXckGCGaE+QOeK2zN4bW9hPzqnKpP0b7Ukf6BE6a9DUCdkQjJnCeUoo5/L+unhetot MiR7Abyf/sL5f60ze+dzbhTA3hyOjVI= Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2176.outbound.protection.outlook.com [104.47.58.176]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-8gHIXDRJO1eiSehMUf9Y5g-1; Wed, 29 Jan 2020 02:03:30 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1349.namprd16.prod.outlook.com (10.172.119.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Wed, 29 Jan 2020 07:03:29 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2665.026; Wed, 29 Jan 2020 07:03:28 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-architecture-16.txt Thread-Index: AQHV1nGyrhpbJ3RU+02hImVktsvFYqgBN1Zg Date: Wed, 29 Jan 2020 07:03:28 +0000 Message-ID: References: <158028115303.4660.5761398190957498256@ietfa.amsl.com> In-Reply-To: <158028115303.4660.5761398190957498256@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9124110a-0867-4de2-fb8a-08d7a48957f4 x-ms-traffictypediagnostic: CY4PR1601MB1349: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(366004)(136003)(39860400002)(346002)(189003)(199004)(32952001)(7696005)(33656002)(66556008)(26005)(186003)(316002)(66476007)(66946007)(76116006)(86362001)(66446008)(64756008)(71200400001)(53546011)(2906002)(6506007)(5660300002)(52536014)(66574012)(966005)(478600001)(81166006)(8936002)(8676002)(81156014)(6916009)(9686003)(55016002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1349; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dnibuwbXoXdLb5v2i1ceejI9jV+9pjMJI8TRKQ988Q0LrCruzJuKLjx1ioJSPDkMfrd7/n1wdVHgyXd6Bp+0brzmJMdZXeQZYmj7J+FOQm0/cB4UbhxARt94wa7pTLzzfbuN6I9zsuYxDMWbdNVtp554iCxnIqy7fPz1t0S7kDNK0HCbYyGGBhvx1BVMqiBpssY/IOJpOUjVVPVsf6Sg/HqAT8ZEPxHgCUYZzgFu/YcoltyCzdCXR2ePVPxqggu8PBSN0vTzBW/G56oQW70c2SKf0GNJz8JB8kHOi11hfTsRnWHwz/R78a5u3zf/PERUrpyoe+KG7Lic8Rc367ZH7pbdb48kA+kVrDfjLyYI+1qI3bOt+h1tYaLaL4xygwKv+xlaLuWGfRgNzCU45xkMRFpafyIQsgVbvmoRyODBT9GvxcgfuH3rOYLWSYkeukrLu69cvfe1HlumQpYBr4ySx9YoibI8jjIZoyKhuAOtU5APDPYP1hf7HqzHpFPEUwwKR0fyiGxKsNf2zxvtZO64DLJ3BbIugZZ6PdNaX8wAswdDAZaZz27RRWJYY+2LUmh4E2qu77HeK9Fz7lSvI7IxDWcvXY21O1icxXsrS9ohkQY= x-ms-exchange-antispam-messagedata: dH6o1iwF30x3r4+5IbwpuvFHoYH5ba24GMBU8pRGrV1iFoZQ4WAekrHm+vDQTrQXUUUej5RLUGs+qoa/ThnTG3M3TlvnME0tU4ondkHGCjOLsjw+CH6NCRYnO0e28N+yZpumPcW+Gsk+k9qNpFDp2A== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9124110a-0867-4de2-fb8a-08d7a48957f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 07:03:28.8442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /dX/L69Yo9ZN26JdhSZM50XYxfFpXfpeiuDoe+iCHMGxqZtX8d8JFDMYkQco/YPQhuQCbR3Bh9gJkMai61NCb4wGgAbckKBspPZOs6E+a5GLLjE5CoimAf7ykmenj4V4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1349 X-MC-Unique: 8gHIXDRJO1eiSehMUf9Y5g-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-architecture-16.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, 29 Jan 2020 07:03:50 -0000 The revised draft addresses comments from Gen-ART and Tsvart. -Tiru > -----Original Message----- > From: Dots On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, January 29, 2020 12:29 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-architecture-16.txt >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed-Denial-of-Service Open Threat Signa= ling (DOTS) > Architecture > Authors : Andrew Mortensen > Tirumaleswar Reddy > Flemming Andreasen > Nik Teague > Rich Compton > =09Filename : draft-ietf-dots-architecture-16.txt > =09Pages : 35 > =09Date : 2020-01-28 >=20 > Abstract: > This document describes an architecture for establishing and > maintaining Distributed Denial of Service (DDoS) Open Threat > Signaling (DOTS) within and between domains. The document does not > specify protocols or protocol extensions, instead focusing on > defining architectural relationships, components and concepts used in > a DOTS deployment. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-architecture-16 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-16 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Jan 29 06: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 0D2C612011A for ; Wed, 29 Jan 2020 06:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3yHD7mkUP7K7 for ; Wed, 29 Jan 2020 06:47:58 -0800 (PST) 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 D11F0120088 for ; Wed, 29 Jan 2020 06:47:57 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4875tz6kT5z2yDw; Wed, 29 Jan 2020 15:47:55 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4875tz5ZDVz1xq0; Wed, 29 Jan 2020 15:47:55 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 29 Jan 2020 15:47:55 +0100 From: To: "dots@ietf.org" , 'kaname nishizuka' Thread-Topic: DOTS Telemetry: URI Path Thread-Index: AdXSA4rBzLMvgmnTQFWFKSY1yB+Z8QEqz0kQ Date: Wed, 29 Jan 2020 14:47:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303141357C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303140D0DC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303140D0DC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303141357COPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry: URI Path X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 14:48:01 -0000 --_000_787AE7BB302AE849A7480A190F8B93303141357COPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We are currently in the process of updating the draft. I'm afraid that we w= ill finaly need to go with more operation path URIs. See inline for more de= tails. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : jeudi 23 janvier 2020 16:41 =C0 : dots@ietf.org; 'kaname nishizuka' Objet : [Dots] DOTS Telemetry: URI Path Hi all, In the current version of the telemetry draft, we are using '/telemetry' fo= r telemetry-related operations. Kaname suggested to define three operation = suffixes for that. I do think that two are sufficient as indicated below: +-------------------------+----------------+ | Operation | Operation Path | +-------------------------+----------------+ | Telemetry Setup | /tm-setup | +-------------------------+----------------+ | Telemetry | /tm | +-------------------------+----------------+ A dedicated uri (/tm-setup) will be used for telemetry setup operations (ba= seline, configuration): see the excerpt below: augment /ietf-signal:dots-signal/ietf-signal:message-type: +--:(telemetry-setup) {dots-telemetry}? | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 | +--rw telemetry-config | | +--rw low-percentile? percentile | | +--rw mid-percentile? percentile | | +--rw high-percentile? percentile | | +--rw unit-config* [unit] | | +--rw unit unit | | +--rw unit-status? Boolean ... | +--rw baseline | +--rw total-pipe-capability* [unit] | | +--rw unit unit | | +--rw pipe? uint64 | +--rw total-traffic-normal-baseline* [unit protocol] | | +--rw unit unit | | +--rw protocol uint8 | | +--rw low-percentile-g? yang:gauge64 | | +--rw mid-percentile-g? yang:gauge64 | | +--rw high-percentile-g? yang:gauge64 | | +--rw peak-g? yang:gauge64 | +--rw total-connection-capacity* [protocol] | +--rw protocol uint8 ... [Med] The current updated tree structure is as follows: augment /ietf-signal:dots-signal/ietf-signal:message-type: +--:(telemetry-setup) {dots-telemetry}? | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 | +--rw telemetry-config | | +--rw measurement-interval? interval | | +--rw measurement-sample? sample | | +--rw low-percentile? percentile | | +--rw mid-percentile? percentile | | +--rw high-percentile? percentile | | +--rw unit-config* [unit] | | +--rw unit unit | | +--rw unit-status? boolean | +--rw total-pipe-capacity* [link-id unit] | | +--rw link-id nt:link-id | | +--rw unit unit | | +--rw pipe? uint64 | +--rw baseline | +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri | +--rw total-traffic-normal-baseline* [unit protocol] | | +--rw unit unit | | +--rw protocol uint8 | | +--rw low-percentile-g? yang:gauge64 | | +--rw mid-percentile-g? yang:gauge64 | | +--rw high-percentile-g? yang:gauge64 | | +--rw peak-g? yang:gauge64 | +--rw total-connection-capacity* [protocol] | +--rw protocol uint8 | +--rw connection? uint64 | +--rw connection-client? uint64 | +--rw embryonic? uint64 | +--rw embryonic-client? uint64 | +--rw connection-ps? uint64 | +--rw connection-client-ps? uint64 | +--rw request-ps? uint64 | +--rw request-client-ps? uint64 | +--rw partial-request-ps? uint64 | +--rw partial-request-client-ps? uint64 The new structure is designed with the following objectives: =B7 Allow a multi-homed client domain to signal the capacity of eac= h interconnection link. =B7 The normal traffic base line can be provided for the overall do= main (an aggregated prefix, or no target-clause included at all) or for spe= cific targets (IP addresses, prefixes) =B7 These parameters can be communicated using the same or distinct= request. Checks on overlapping targets and links are covered. Nevertheless, this design brings some complexity if a request overlaps with= an existing pipe request but a new baseline traffic. We may either go for = an additional uri or maintain one single uri but go with the following desi= gn (which is my favorite): augment /ietf-signal:dots-signal/ietf-signal:message-type: +--:(telemetry-setup) {dots-telemetry}? | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 | +--rw (setup-type)? | +--:(telemetry-config) | | +--rw measurement-interval? interval | | +--rw measurement-sample? sample | | +--rw low-percentile? percentile | | +--rw mid-percentile? percentile | | +--rw high-percentile? percentile | | +--rw unit-config* [unit] | | +--rw unit unit | | +--rw unit-status? boolean | +--:(pipe) | | +--rw total-pipe-capacity* [link-id unit] | | +--rw link-id nt:link-id | | +--rw unit unit | | +--rw pipe? uint64 | +--:(baseline) | +--rw baseline | +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri | +--rw total-traffic-normal-baseline* [unit protocol] | | +--rw unit unit | | +--rw protocol uint8 | | +--rw low-percentile-g? yang:gauge64 | | +--rw mid-percentile-g? yang:gauge64 | | +--rw high-percentile-g? yang:gauge64 | | +--rw peak-g? yang:gauge64 | +--rw total-connection-capacity* [protocol] | +--rw protocol uint8 | +--rw connection? uint64 | +--rw connection-client? uint64 | +--rw embryonic? uint64 | +--rw embryonic-client? uint64 | +--rw connection-ps? uint64 | +--rw connection-client-ps? uint64 | +--rw request-ps? uint64 | +--rw request-client-ps? uint64 | +--rw partial-request-ps? uint64 Thoughts? While '/tm' can be used for sharing pre-mitigation telemetry data (an excer= pt of the tree is shown below). +--:(telemetry) {dots-telemetry}? +--rw pre-mitigation* [cuid telemetry-id] +--rw cuid string +--rw cdid? string +--rw telemetry-id uint32 +--rw target | +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri +--ro total-attack-traffic* [unit protocol] | +--ro unit unit | +--ro protocol uint8 | +--ro low-percentile-g? yang:gauge64 | +--ro mid-percentile-g? yang:gauge64 | +--ro high-percentile-g? yang:gauge64 | +--ro peak-g? yang:gauge64 +--ro total-traffic* [unit protocol] ... +--ro attack-detail +--ro vendor-id? uint32 +--ro attack-id? string +--ro attack-name? string +--ro attack-severity? attack-severity +--ro start-time? uint64 +--ro end-time? uint64 +--ro source-count | +--ro low-percentile-g? yang:gauge64 | +--ro mid-percentile-g? yang:gauge64 | +--ro high-percentile-g? yang:gauge64 | +--ro peak-g? yang:gauge64 +--ro top-talker +--ro source-prefix* [source-prefix] +--ro spoofed-status? boolean +--ro source-prefix inet:ip-prefix ... Unless there are objections, we will implement this change in the next iter= ation of the draft. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93303141357COPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We are currently in the process of updating the draft. I̵= 7;m afraid that we will finaly need to go with more operation path URIs. Se= e inline for more details.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : jeudi 23 janvier 2020 16:41
=C0 : dots@ietf.org; 'kaname nishizuka'
Objet : [Dots] DOTS Telemetry: URI Path

 

= Hi all,

=  

= In the current version of the telemetry draft, we are using ‘/telemet= ry’ for telemetry-related operations. Kaname suggested to define thre= e operation suffixes for that. I do think that two are sufficient as indicated below:

=  

=          +---------------------= ----+----------------+

=          | Operation  &nb= sp;            | Ope= ration Path |

=          +---------------------= ----+----------------+

=          | Telemetry Setup &nb= sp;       | /tm-setup    =   |

=          +---------------------= ----+----------------+

=          | Telemetry  &nb= sp;            | /tm=             |

=          +---------------------= ----+----------------+

=  

= A dedicated uri (/tm-setup) will be used for telemetry setup operations (ba= seline, configuration): see the excerpt below:

=  

  augment /ietf-signa= l:dots-signal/ietf-signal:message-type:

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

    | = +--rw telemetry* [cuid tsid]

    | =     +--rw cuid       =          string

    | =     +--rw cdid?       = ;        string

    | =     +--rw tsid       =          uint32

    | =     +--rw telemetry-config

    | =     |  +--rw low-percentile?    perc= entile

    | =     |  +--rw mid-percentile?    perc= entile

    | =     |  +--rw high-percentile?   percentil= e

    | =     |  +--rw unit-config* [unit]<= /p>

    | =     |     +--rw unit  &nbs= p;        unit

    | =     |     +--rw unit-status? &n= bsp; Boolean

    &n= bsp;       …

    | =     +--rw baseline

    | =        +--rw total-pipe-capability* [unit= ]

    | =        |  +--rw unit  &nbs= p; unit

    | =        |  +--rw pipe?   ui= nt64

    | =        +--rw total-traffic-normal-baselin= e* [unit protocol]

    | =        |  +--rw unit   &nb= sp;            =  unit

    | =        |  +--rw protocol  =            uint8

    | =        |  +--rw low-percentile-g?&nb= sp;   yang:gauge64

    | =        |  +--rw mid-percentile-g?&nb= sp;   yang:gauge64

    | =        |  +--rw high-percentile-g?&n= bsp;  yang:gauge64

    | =        |  +--rw peak-g?  &= nbsp;           yang:gaug= e64

    | =        +--rw total-connection-capacity* [= protocol]

    | =           +--rw protocol&n= bsp;            = ;        uint8    &n= bsp;

    &n= bsp; …

[Med] The current updated= tree structure is as follows:

 <= /i>

=  = augment /ietf-signal:dots-signal/ietf-signal:message-type:

=  =    +--:(telemetry-setup) {dots-telemetry}?<= /i>

=  =    |  +--rw telemetry* [cuid tsid]=

=  =    |     +--rw cuid   &nbs= p;            &= nbsp;  string

=  =    |     +--rw cdid?   &nb= sp;            =   string

=  =    |     +--rw tsid   &nbs= p;            &= nbsp;  uint32

=  =    |     +--rw telemetry-config

=  =    |     |  +--rw measurement-interv= al?   interval

=  =    |     |  +--rw measurement-sample= ?     sample

=  =    |     |  +--rw low-percentile?&nb= sp;        percentile<= /i>

=  =    |     |  +--rw mid-percentile?&nb= sp;        percentile<= /i>

=  =    |     |  +--rw high-percentile?&n= bsp;       percentile

=  =    |     |  +--rw unit-config* [unit= ]

=  =    |     |     +--rw = unit           unit<= /o:p>

=  =    |     |     +--rw = unit-status?   boolean

=  =    |     +--rw total-pipe-capacity* [link= -id unit]

=  =    |     |  +--rw link-id  = ;  nt:link-id

=  =    |     |  +--rw unit  &n= bsp;    unit

=  =    |     |  +--rw pipe?  &= nbsp;   uint64

=  =    |     +--rw baseline=

=  =    |        +--rw target-p= refix*           &nb= sp;       inet:ip-prefix

=  =    |        +--rw target-p= ort-range* [lower-port]

=  =    |        |  +--rw = lower-port    inet:port-number

=  =    |        |  +--rw = upper-port?   inet:port-number

=  =    |        +--rw target-p= rotocol*           &= nbsp;     uint8

=  =    |        +--rw target-f= qdn*            = ;         inet:domain-name

=  =    |        +--rw target-u= ri*            =           inet:uri<= /span>

=  =    |        +--rw total-tr= affic-normal-baseline* [unit protocol]

=  =    |        |  +--rw = unit            = ;     unit

=  =    |        |  +--rw = protocol           &= nbsp; uint8

=  =    |        |  +--rw = low-percentile-g?    yang:gauge64<= /p>

=  =    |        |  +--rw = mid-percentile-g?    yang:gauge64<= /p>

=  =    |        |  +--rw = high-percentile-g?   yang:gauge64

=  =    |        |  +--rw = peak-g?           &n= bsp;  yang:gauge64

=  =    |        +--rw total-co= nnection-capacity* [protocol]

=  =    |           = +--rw protocol         &nb= sp;           uint8<= /o:p>

=  =    |           = +--rw connection?         =          uint64

=  =    |           = +--rw connection-client?        = ;   uint64

=  =    |           = +--rw embryonic?         &= nbsp;         uint64

=  =    |           = +--rw embryonic-client?        =     uint64

=  =    |           = +--rw connection-ps?        &nb= sp;      uint64

=  =    |           = +--rw connection-client-ps?        u= int64

=  =    |           = +--rw request-ps?         =          uint64

=  =    |           = +--rw request-client-ps?        = ;   uint64

=  =    |           = +--rw partial-request-ps?       &nbs= p;  uint64

    | = ;          +--rw partial-r= equest-client-ps?   uint64

 <= /i>

The new structure is desi= gned with the following objectives:

=B7         Allow a multi-homed client domain to signal the= capacity of each interconnection link.

=B7         The normal traffic base line can be provided fo= r the overall domain (an aggregated prefix, or no target-clause included at= all) or for specific targets (IP addresses, prefixes)

=B7         These parameters can be communicated using the = same or distinct request. Checks on overlapping targets and links are cover= ed.

 <= /i>

Nevertheless, this design= brings some complexity if a request overlaps with an existing pipe request= but a new baseline traffic. We may either go for an additional uri or maintain one single uri but go with the following des= ign (which is my favorite):

 <= /i>

  augment /ietf-signal:dots-signal/ietf-signal:message-t= ype:

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

    |  +--rw telemetry* [cuid tsid]

    |     +--rw cuid&n= bsp;            = ;             s= tring

    |     +--rw cdid?&= nbsp;            &nb= sp;           string=

    |     +--rw tsid&n= bsp;            = ;             u= int32

    |     +--rw (setup= -type)?

    |       = ; +--:(telemetry-config)

    |       = ; |  +--rw measurement-interval?   interval

    |       = ; |  +--rw measurement-sample?     sample=

    |       = ; |  +--rw low-percentile?      &nbs= p;  percentile

    |       = ; |  +--rw mid-percentile?      &nbs= p;  percentile

    |       = ; |  +--rw high-percentile?      &nb= sp; percentile

    |       = ; |  +--rw unit-config* [unit]

    |       = ; |     +--rw unit     &nb= sp;     unit

    |       = ; |     +--rw unit-status?   boolean=

    |       = ; +--:(pipe)

    |       = ; |  +--rw total-pipe-capacity* [link-id unit]

    |       = ; |     +--rw link-id    nt:link-id<= o:p>

    |       = ; |     +--rw unit     &nb= sp; unit

    |       = ; |     +--rw pipe?      u= int64

    |       = ; +--:(baseline)

    |       = ;    +--rw baseline

    |       = ;       +--rw target-prefix*  &= nbsp;           &nbs= p;    inet:ip-prefix

    |       = ;       +--rw target-port-range* [lower-p= ort]

    |       = ;       |  +--rw lower-port &nb= sp;  inet:port-number

    |       = ;       |  +--rw upper-port? &n= bsp; inet:port-number

    |       = ;       +--rw target-protocol*  = ;            &n= bsp;  uint8

    |       = ;       +--rw target-fqdn*  &nb= sp;            =       inet:domain-name

    |       = ;       +--rw target-uri*  &nbs= p;            &= nbsp;      inet:uri

    |       = ;       +--rw total-traffic-normal-baseli= ne* [unit protocol]

    |       = ;       |  +--rw unit  &nb= sp;            =   unit

    |       = ;       |  +--rw protocol  = ;           uint8

    |       = ;       |  +--rw low-percentile-g?&n= bsp;   yang:gauge64

    |       = ;       |  +--rw mid-percentile-g?&n= bsp;   yang:gauge64

    |       = ;       |  +--rw high-percentile-g?&= nbsp;  yang:gauge64

    |       = ;       |  +--rw peak-g?  =             yang:gau= ge64

    |       = ;       +--rw total-connection-capacity* = [protocol]

    |       = ;          +--rw protocol&= nbsp;           &nbs= p;        uint8

    |       = ;          +--rw connectio= n?            &= nbsp;     uint64

    |       = ;          +--rw connectio= n-client?           uint6= 4

    |       = ;          +--rw embryonic= ?             &= nbsp;     uint64

    |       = ;          +--rw embryonic= -client?            = uint64

    |       = ;          +--rw connectio= n-ps?           &nbs= p;   uint64

    |       = ;          +--rw connectio= n-client-ps?        uint64

    |       = ;          +--rw request-p= s?             =      uint64

    |       = ;          +--rw request-c= lient-ps?           uint6= 4

    |       = ;          +--rw partial-r= equest-ps?          uint64

Thoughts?<= span style=3D"font-family:"Courier New";color:#1F497D">

=  

= While ‘/tm’ can be used for sharing pre-mitigation telemetry da= ta (an excerpt of the tree is shown below).

=  

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

    &n= bsp;  +--rw pre-mitigation* [cuid telemetry-id]<= /p>

    &n= bsp;     +--rw cuid     &n= bsp;            = ;     string

    &n= bsp;     +--rw cdid?     &= nbsp;           &nbs= p;    string

    &n= bsp;     +--rw telemetry-id    =            uint32

    &n= bsp;     +--rw target

    &n= bsp;     |  +--rw target-prefix*  &n= bsp;    inet:ip-prefix

    &n= bsp;     |  +--rw target-port-range* [lower-po= rt]

    &n= bsp;     |  |  +--rw lower-port &nbs= p;  inet:port-number

    &n= bsp;     |  |  +--rw upper-port? &nb= sp; inet:port-number

    &n= bsp;     |  +--rw target-protocol*  =    uint8

    &n= bsp;     |  +--rw target-fqdn*  &nbs= p;      inet:domain-name

    &n= bsp;     |  +--rw target-uri*   = ;       inet:uri

    &n= bsp;     +--ro total-attack-traffic* [unit protocol= ]

    &n= bsp;     |  +--ro unit    =              un= it

    &n= bsp;     |  +--ro protocol   &n= bsp;         uint8

    &n= bsp;     |  +--ro low-percentile-g?  = ;  yang:gauge64

    &n= bsp;     |  +--ro mid-percentile-g?  = ;  yang:gauge64

    &n= bsp;     |  +--ro high-percentile-g? &nbs= p; yang:gauge64

    &n= bsp;     |  +--ro peak-g?   &nb= sp;          yang:gauge64=

    &n= bsp;     +--ro total-traffic* [unit protocol]<= /o:p>

    &n= bsp;     …

    &n= bsp;     +--ro attack-detail

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

    &n= bsp;        +--ro attack-id? &n= bsp;       string

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

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

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

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

    &n= bsp;        +--ro source-count<= /o:p>

    &n= bsp;        |  +--ro low-percen= tile-g?    yang:gauge64

    &n= bsp;        |  +--ro mid-percen= tile-g?    yang:gauge64

    &n= bsp;        |  +--ro high-perce= ntile-g?   yang:gauge64

    &n= bsp;        |  +--ro peak-g?&nb= sp;            = yang:gauge64

    &n= bsp;        +--ro top-talker

    &n= bsp;           +--ro = source-prefix* [source-prefix]

    &n= bsp;            = ;  +--ro spoofed-status?       =      boolean

    &n= bsp;            = ;  +--ro source-prefix       &n= bsp;      inet:ip-prefix

    &n= bsp;           …

=  

= Unless there are objections, we will implement this change in the next iter= ation of the draft.

=  

= Cheers,

= Med

--_000_787AE7BB302AE849A7480A190F8B93303141357COPEXCAUBMA2corp_-- From nobody Thu Jan 30 18:10:28 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668C112080E for ; Thu, 30 Jan 2020 18:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nttv6.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSQCaPYofozr for ; Thu, 30 Jan 2020 18:10:23 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 88070120019 for ; Thu, 30 Jan 2020 18:10:22 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 1335F25F751; Fri, 31 Jan 2020 11:10:20 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1580436620; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yHDMRQ6r7mQVRZbhnJ9MupCBg182u5v9Y0YtTfCuz14=; b=a0sX8lOqOb9/9ls9+lyUPCTkmi6OeAwBtt2KDLBY+rH8CcwblUO+7dKwRgbXIFhfwHU1lR KnxEC71xqv9BdrEtULQN3Rm8GP7oa59zrJtvmL4KS5qB6WJpSQnKfYy/qDjv/FHwAQ3D+9 Wzt4WqC9/EZJZIguul9M7qGkQVBjYxM= Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 0052475906F; Fri, 31 Jan 2020 11:10:19 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B93303140D0DC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303141357C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <70510b36-aac4-db69-c88c-3204894f92c0@nttv6.jp> Date: Fri, 31 Jan 2020 11:10:19 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93303141357C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------3BE20D40B4706AC000FD9DF6" Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] DOTS Telemetry: URI Path 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, 31 Jan 2020 02:10:27 -0000 This is a multi-part message in MIME format. --------------3BE20D40B4706AC000FD9DF6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Med, As per the hackathon report of the last IETF, Server to Client telemetry would require another URI in order to convey asynchronous notification of attack-details from a DOTS server. https://datatracker.ietf.org/meeting/106/materials/slides-106-dots-dots-telemetry-related-hackathon-activity-report-00 slide 9. I'd like to hear notions whether that is already taken into account or not. Second, regarding with machine learning capability of DOTS, we've noticed some costomized feature like a ratio of SYN versus ACK in TCP flag is contributing for precise attack detection (in a feature construction process which is for obtaining contributing features from several metrics). At the last meeting, we've discussed that conveying normal metric is already done by IPFIX. But should adding this kind of DDoS dedicated metric be done in IPFIX or DOTS? thanks, Kaname On 2020/01/29 23:47, mohamed.boucadair@orange.com wrote: > > Hi all, > > We are currently in the process of updating the draft. I’m afraid that we will finaly need to go with more operation path URIs. See inline for more details. > > Cheers, > > Med > > *De :*Dots [mailto:dots-bounces@ietf.org] *De la part de* mohamed.boucadair@orange.com > *Envoyé :* jeudi 23 janvier 2020 16:41 > *À :* dots@ietf.org; 'kaname nishizuka' > *Objet :* [Dots] DOTS Telemetry: URI Path > > Hi all, > > In the current version of the telemetry draft, we are using ‘/telemetry’ for telemetry-related operations. Kaname suggested to define three operation suffixes for that. I do think that two are sufficient as indicated below: > > +-------------------------+----------------+ > >          | Operation               | Operation Path | > > +-------------------------+----------------+ > >          | Telemetry Setup         | /tm-setup      | > > +-------------------------+----------------+ > >          | Telemetry               | /tm            | > > +-------------------------+----------------+ > > A dedicated uri (/tm-setup) will be used for telemetry setup operations (baseline, configuration): see the excerpt below: > >   augment /ietf-signal:dots-signal/ietf-signal:message-type: > >     +--:(telemetry-setup) {dots-telemetry}? > >     |  +--rw telemetry* [cuid tsid] > >     |     +--rw cuid                string > >     |     +--rw cdid?               string > >     |     +--rw tsid                uint32 > >     |     +--rw telemetry-config > >     |     |  +--rw low-percentile? percentile > >     |     |  +--rw mid-percentile? percentile > >     |     |  +--rw high-percentile? percentile > >     |     |  +--rw unit-config* [unit] > >     |     |     +--rw unit           unit > >     |     |     +--rw unit-status? Boolean > >             … > >     |     +--rw baseline > >     |        +--rw total-pipe-capability* [unit] > >     |        |  +--rw unit    unit > >     |        |  +--rw pipe?   uint64 > >     |        +--rw total-traffic-normal-baseline* [unit protocol] > >     |        |  +--rw unit                 unit > >     |        |  +--rw protocol uint8 > >     |        |  +--rw low-percentile-g? yang:gauge64 > >     |        |  +--rw mid-percentile-g? yang:gauge64 > >     |        |  +--rw high-percentile-g? yang:gauge64 > >     |        |  +--rw peak-g? yang:gauge64 > >     |        +--rw total-connection-capacity* [protocol] > >     |           +--rw protocol                     uint8 > >       … > > */[Med] The current updated tree structure is as follows: /* > > *//* > > */  augment /ietf-signal:dots-signal/ietf-signal:message-type:/* > > */    +--:(telemetry-setup) {dots-telemetry}?/* > > */    |  +--rw telemetry* [cuid tsid]/* > > */    |     +--rw cuid                   string/* > > */    |     +--rw cdid?                  string/* > > */    |     +--rw tsid                   uint32/* > > */    |     +--rw telemetry-config/* > > */    |     |  +--rw measurement-interval?   interval/* > > */    |     |  +--rw measurement-sample?     sample/* > > */    |     |  +--rw low-percentile?         percentile/* > > */    |     |  +--rw mid-percentile?         percentile/* > > */    |     |  +--rw high-percentile?        percentile/* > > */    |     |  +--rw unit-config* [unit]/* > > */    |     |     +--rw unit           unit/* > > */    |     |     +--rw unit-status?   boolean/* > > */    |     +--rw total-pipe-capacity* [link-id unit]/* > > */    |     |  +--rw link-id nt:link-id/* > > */    |     |  +--rw unit unit/* > > */    |     |  +--rw pipe? uint64/* > > */    |     +--rw baseline/* > > */    |        +--rw target-prefix*                   inet:ip-prefix/* > > */    |        +--rw target-port-range* [lower-port]/* > > */    |        |  +--rw lower-port    inet:port-number/* > > */    |        |  +--rw upper-port?   inet:port-number/* > > */    |        +--rw target-protocol*                 uint8/* > > */    |        +--rw target-fqdn*                     inet:domain-name/* > > */    |        +--rw target-uri*                      inet:uri/* > > */    |        +--rw total-traffic-normal-baseline* [unit protocol]/* > > */    |        |  +--rw unit                 unit/* > > */    |        |  +--rw protocol             uint8/* > > */    |        |  +--rw low-percentile-g?    yang:gauge64/* > > */    |        |  +--rw mid-percentile-g?    yang:gauge64/* > > */    |        |  +--rw high-percentile-g?   yang:gauge64/* > > */    |        |  +--rw peak-g?              yang:gauge64/* > > */    |        +--rw total-connection-capacity* [protocol]/* > > */    |           +--rw protocol                     uint8/* > > */    |           +--rw connection?                  uint64/* > > */    |           +--rw connection-client?           uint64/* > > */    |           +--rw embryonic?                   uint64/* > > */    |           +--rw embryonic-client?            uint64/* > > */    |           +--rw connection-ps?               uint64/* > > */    |           +--rw connection-client-ps?        uint64/* > > */    |           +--rw request-ps?                  uint64/* > > */    |           +--rw request-client-ps?           uint64/* > > */    |           +--rw partial-request-ps?          uint64/* > > */    |           +--rw partial-request-client-ps?   uint64/* > > *//* > > */The new structure is designed with the following objectives:/* > > ·*/Allow a multi-homed client domain to signal the capacity of each interconnection link. /* > > ·*/The normal traffic base line can be provided for the overall domain (an aggregated prefix, or no target-clause included at all) or for specific targets (IP addresses, prefixes)/* > > ·*/These parameters can be communicated using the same or distinct request. Checks on overlapping targets and links are covered. /* > > *//* > > */Nevertheless, this design brings some complexity if a request overlaps with an existing pipe request but a new baseline traffic. We may either go for an additional uri or maintain one single uri but go with the following design (which is my favorite):/* > > *//* > >   augment /ietf-signal:dots-signal/ietf-signal:message-type: > >     +--:(telemetry-setup) {dots-telemetry}? > >     |  +--rw telemetry* [cuid tsid] > >     |     +--rw cuid                          string > >     |     +--rw cdid?                     string > >     |     +--rw tsid                          uint32 > >     |     +--rw (setup-type)? > >     | +--:(telemetry-config) > >     |        |  +--rw measurement-interval?   interval > >     |        |  +--rw measurement-sample?     sample > >     |        |  +--rw low-percentile?         percentile > >     |        |  +--rw mid-percentile?         percentile > >     |        |  +--rw high-percentile?        percentile > >     |        |  +--rw unit-config* [unit] > >     |        |     +--rw unit           unit > >     |        |     +--rw unit-status?   boolean > >     |        +--:(pipe) > >     |        |  +--rw total-pipe-capacity* [link-id unit] > >     |        |     +--rw link-id    nt:link-id > >     |        |     +--rw unit       unit > >     |        |     +--rw pipe?      uint64 > >     |        +--:(baseline) > >     |           +--rw baseline > >     |              +--rw target-prefix*                   inet:ip-prefix > >     |              +--rw target-port-range* [lower-port] > >     |              |  +--rw lower-port    inet:port-number > >     |              |  +--rw upper-port?   inet:port-number > >     |              +--rw target-protocol*                 uint8 > >     |              +--rw target-fqdn*                     inet:domain-name > >     |              +--rw target-uri*                      inet:uri > >     |              +--rw total-traffic-normal-baseline* [unit protocol] > >     |              |  +--rw unit                 unit > >     |              |  +--rw protocol             uint8 > >     |              |  +--rw low-percentile-g?    yang:gauge64 > >     |              |  +--rw mid-percentile-g?    yang:gauge64 > >     |              |  +--rw high-percentile-g?   yang:gauge64 > >     |              |  +--rw peak-g?              yang:gauge64 > >     |              +--rw total-connection-capacity* [protocol] > >     |                 +--rw protocol                     uint8 > >     |                 +--rw connection?                  uint64 > >     |                 +--rw connection-client?           uint64 > >     |                 +--rw embryonic?                   uint64 > >     |                 +--rw embryonic-client?            uint64 > >     |                 +--rw connection-ps?               uint64 > >     |                 +--rw connection-client-ps?        uint64 > >     |                 +--rw request-ps?                  uint64 > >     |                 +--rw request-client-ps?           uint64 > >     |                 +--rw partial-request-ps?          uint64 > > *//* > > */Thoughts?/* > > While ‘/tm’ can be used for sharing pre-mitigation telemetry data (an excerpt of the tree is shown below). > >     +--:(telemetry) {dots-telemetry}? > >        +--rw pre-mitigation* [cuid telemetry-id] > >           +--rw cuid string > >           +--rw cdid? string > >           +--rw telemetry-id uint32 > >           +--rw target > >           |  +--rw target-prefix* inet:ip-prefix > >           |  +--rw target-port-range* [lower-port] > >           |  |  +--rw lower-port inet:port-number > >           |  |  +--rw upper-port? inet:port-number > >           |  +--rw target-protocol* uint8 > >           |  +--rw target-fqdn* inet:domain-name > >           |  +--rw target-uri* inet:uri > >           +--ro total-attack-traffic* [unit protocol] > >           |  +--ro unit unit > >           |  +--ro protocol uint8 > >           |  +--ro low-percentile-g? yang:gauge64 > >           |  +--ro mid-percentile-g? yang:gauge64 > >           |  +--ro high-percentile-g? yang:gauge64 > >           |  +--ro peak-g? yang:gauge64 > >           +--ro total-traffic* [unit protocol] > >           … > >           +--ro attack-detail > >              +--ro vendor-id? uint32 > >              +--ro attack-id? string > >              +--ro attack-name? string > >              +--ro attack-severity? attack-severity > >              +--ro start-time? uint64 > >              +--ro end-time? uint64 > >              +--ro source-count > >              |  +--ro low-percentile-g? yang:gauge64 > >              |  +--ro mid-percentile-g? yang:gauge64 > >              |  +--ro high-percentile-g? yang:gauge64 > >              |  +--ro peak-g? yang:gauge64 > >              +--ro top-talker > >                 +--ro source-prefix* [source-prefix] > >                    +--ro spoofed-status?            boolean > >                    +--ro source-prefix              inet:ip-prefix > >                 … > > Unless there are objections, we will implement this change in the next iteration of the draft. > > Cheers, > > Med > --------------3BE20D40B4706AC000FD9DF6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Med,

As per the hackathon report of the last IETF, Server to Client telemetry would require another URI in order to convey asynchronous notification of attack-details from a DOTS server.
https://datatracker.ietf.org/meeting/106/materials/slides-106-dots-dots-telemetry-related-hackathon-activity-report-00
slide 9.
I'd like to hear notions whether that is already taken into account or not.

Second, regarding with machine learning capability of DOTS, we've noticed some costomized feature like a ratio of SYN versus ACK in TCP flag is contributing for precise attack detection (in a feature construction process which is for obtaining contributing features from several metrics).
At the last meeting, we've discussed that conveying normal metric is already done by IPFIX.
But should adding this kind of DDoS dedicated metric be done in IPFIX or DOTS?

thanks,
Kaname

On 2020/01/29 23:47, mohamed.boucadair@orange.com wrote:

Hi all,

 

We are currently in the process of updating the draft. I’m afraid that we will finaly need to go with more operation path URIs. See inline for more details.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoyé : jeudi 23 janvier 2020 16:41
À : dots@ietf.org; 'kaname nishizuka'
Objet : [Dots] DOTS Telemetry: URI Path

 

Hi all,

 

In the current version of the telemetry draft, we are using ‘/telemetry’ for telemetry-related operations. Kaname suggested to define three operation suffixes for that. I do think that two are sufficient as indicated below:

 

         +-------------------------+----------------+

         | Operation               | Operation Path |

         +-------------------------+----------------+

         | Telemetry Setup         | /tm-setup      |

         +-------------------------+----------------+

         | Telemetry               | /tm            |

         +-------------------------+----------------+

 

A dedicated uri (/tm-setup) will be used for telemetry setup operations (baseline, configuration): see the excerpt below:

 

  augment /ietf-signal:dots-signal/ietf-signal:message-type:

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

    |  +--rw telemetry* [cuid tsid]

    |     +--rw cuid                string

    |     +--rw cdid?               string

    |     +--rw tsid                uint32

    |     +--rw telemetry-config

    |     |  +--rw low-percentile?    percentile

    |     |  +--rw mid-percentile?    percentile

    |     |  +--rw high-percentile?   percentile

    |     |  +--rw unit-config* [unit]

    |     |     +--rw unit           unit

    |     |     +--rw unit-status?   Boolean

            …

    |     +--rw baseline

    |        +--rw total-pipe-capability* [unit]

    |        |  +--rw unit    unit

    |        |  +--rw pipe?   uint64

    |        +--rw total-traffic-normal-baseline* [unit protocol]

    |        |  +--rw unit                 unit

    |        |  +--rw protocol             uint8

    |        |  +--rw low-percentile-g?    yang:gauge64

    |        |  +--rw mid-percentile-g?    yang:gauge64

    |        |  +--rw high-percentile-g?   yang:gauge64

    |        |  +--rw peak-g?              yang:gauge64

    |        +--rw total-connection-capacity* [protocol]

    |           +--rw protocol                     uint8     

      …

[Med] The current updated tree structure is as follows:

 

  augment /ietf-signal:dots-signal/ietf-signal:message-type:

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

    |  +--rw telemetry* [cuid tsid]

    |     +--rw cuid                   string

    |     +--rw cdid?                  string

    |     +--rw tsid                   uint32

    |     +--rw telemetry-config

    |     |  +--rw measurement-interval?   interval

    |     |  +--rw measurement-sample?     sample

    |     |  +--rw low-percentile?         percentile

    |     |  +--rw mid-percentile?         percentile

    |     |  +--rw high-percentile?        percentile

    |     |  +--rw unit-config* [unit]

    |     |     +--rw unit           unit

    |     |     +--rw unit-status?   boolean

    |     +--rw total-pipe-capacity* [link-id unit]

    |     |  +--rw link-id    nt:link-id

    |     |  +--rw unit       unit

    |     |  +--rw pipe?      uint64

    |     +--rw baseline

    |        +--rw target-prefix*                   inet:ip-prefix

    |        +--rw target-port-range* [lower-port]

    |        |  +--rw lower-port    inet:port-number

    |        |  +--rw upper-port?   inet:port-number

    |        +--rw target-protocol*                 uint8

    |        +--rw target-fqdn*                     inet:domain-name

    |        +--rw target-uri*                      inet:uri

    |        +--rw total-traffic-normal-baseline* [unit protocol]

    |        |  +--rw unit                 unit

    |        |  +--rw protocol             uint8

    |        |  +--rw low-percentile-g?    yang:gauge64

    |        |  +--rw mid-percentile-g?    yang:gauge64

    |        |  +--rw high-percentile-g?   yang:gauge64

    |        |  +--rw peak-g?              yang:gauge64

    |        +--rw total-connection-capacity* [protocol]

    |           +--rw protocol                     uint8

    |           +--rw connection?                  uint64

    |           +--rw connection-client?           uint64

    |           +--rw embryonic?                   uint64

    |           +--rw embryonic-client?            uint64

    |           +--rw connection-ps?               uint64

    |           +--rw connection-client-ps?        uint64

    |           +--rw request-ps?                  uint64

    |           +--rw request-client-ps?           uint64

    |           +--rw partial-request-ps?          uint64

    |           +--rw partial-request-client-ps?   uint64

 

The new structure is designed with the following objectives:

·         Allow a multi-homed client domain to signal the capacity of each interconnection link.

·         The normal traffic base line can be provided for the overall domain (an aggregated prefix, or no target-clause included at all) or for specific targets (IP addresses, prefixes)

·         These parameters can be communicated using the same or distinct request. Checks on overlapping targets and links are covered.

 

Nevertheless, this design brings some complexity if a request overlaps with an existing pipe request but a new baseline traffic. We may either go for an additional uri or maintain one single uri but go with the following design (which is my favorite):

 

  augment /ietf-signal:dots-signal/ietf-signal:message-type:

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

    |  +--rw telemetry* [cuid tsid]

    |     +--rw cuid                          string

    |     +--rw cdid?                         string

    |     +--rw tsid                          uint32

    |     +--rw (setup-type)?

    |        +--:(telemetry-config)

    |        |  +--rw measurement-interval?   interval

    |        |  +--rw measurement-sample?     sample

    |        |  +--rw low-percentile?         percentile

    |        |  +--rw mid-percentile?         percentile

    |        |  +--rw high-percentile?        percentile

    |        |  +--rw unit-config* [unit]

    |        |     +--rw unit           unit

    |        |     +--rw unit-status?   boolean

    |        +--:(pipe)

    |        |  +--rw total-pipe-capacity* [link-id unit]

    |        |     +--rw link-id    nt:link-id

    |        |     +--rw unit       unit

    |        |     +--rw pipe?      uint64

    |        +--:(baseline)

    |           +--rw baseline

    |              +--rw target-prefix*                   inet:ip-prefix

    |              +--rw target-port-range* [lower-port]

    |              |  +--rw lower-port    inet:port-number

    |              |  +--rw upper-port?   inet:port-number

    |              +--rw target-protocol*                 uint8

    |              +--rw target-fqdn*                     inet:domain-name

    |              +--rw target-uri*                      inet:uri

    |              +--rw total-traffic-normal-baseline* [unit protocol]

    |              |  +--rw unit                 unit

    |              |  +--rw protocol             uint8

    |              |  +--rw low-percentile-g?    yang:gauge64

    |              |  +--rw mid-percentile-g?    yang:gauge64

    |              |  +--rw high-percentile-g?   yang:gauge64

    |              |  +--rw peak-g?              yang:gauge64

    |              +--rw total-connection-capacity* [protocol]

    |                 +--rw protocol                     uint8

    |                 +--rw connection?                  uint64

    |                 +--rw connection-client?           uint64

    |                 +--rw embryonic?                   uint64

    |                 +--rw embryonic-client?            uint64

    |                 +--rw connection-ps?               uint64

    |                 +--rw connection-client-ps?        uint64

    |                 +--rw request-ps?                  uint64

    |                 +--rw request-client-ps?           uint64

    |                 +--rw partial-request-ps?          uint64

Thoughts?

 

While ‘/tm’ can be used for sharing pre-mitigation telemetry data (an excerpt of the tree is shown below).

 

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

       +--rw pre-mitigation* [cuid telemetry-id]

          +--rw cuid                       string

          +--rw cdid?                      string

          +--rw telemetry-id               uint32

          +--rw target

          |  +--rw target-prefix*       inet:ip-prefix

          |  +--rw target-port-range* [lower-port]

          |  |  +--rw lower-port    inet:port-number

          |  |  +--rw upper-port?   inet:port-number

          |  +--rw target-protocol*     uint8

          |  +--rw target-fqdn*         inet:domain-name

          |  +--rw target-uri*          inet:uri

          +--ro total-attack-traffic* [unit protocol]

          |  +--ro unit                 unit

          |  +--ro protocol             uint8

          |  +--ro low-percentile-g?    yang:gauge64

          |  +--ro mid-percentile-g?    yang:gauge64

          |  +--ro high-percentile-g?   yang:gauge64

          |  +--ro peak-g?              yang:gauge64

          +--ro total-traffic* [unit protocol]

          …

          +--ro attack-detail

             +--ro vendor-id?         uint32

             +--ro attack-id?         string

             +--ro attack-name?       string

             +--ro attack-severity?   attack-severity

             +--ro start-time?        uint64

             +--ro end-time?          uint64

             +--ro source-count

             |  +--ro low-percentile-g?    yang:gauge64

             |  +--ro mid-percentile-g?    yang:gauge64

             |  +--ro high-percentile-g?   yang:gauge64

             |  +--ro peak-g?              yang:gauge64

             +--ro top-talker

                +--ro source-prefix* [source-prefix]

                   +--ro spoofed-status?            boolean

                   +--ro source-prefix              inet:ip-prefix

                …

 

Unless there are objections, we will implement this change in the next iteration of the draft.

 

Cheers,

Med


--------------3BE20D40B4706AC000FD9DF6-- From nobody Thu Jan 30 23:41: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 66491120059 for ; Thu, 30 Jan 2020 23:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 S9aba5Nv0i0Y for ; Thu, 30 Jan 2020 23:41:11 -0800 (PST) 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 9898C12001E for ; Thu, 30 Jan 2020 23:41:10 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4888Kc5w92z1y9y; Fri, 31 Jan 2020 08:41:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1580456468; bh=mpUuFQXz7SiXouenN5sTfWj/o1pSgN3VRkXk63c5So8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=uZZLvkRtEiRAHUzAH9uv5vlgm6TkubskB4xeb66O/1rfeUay3xgFs6QYtk3fM4DZ+ 0OXrP7+dnVB9aW3ebgKl26uBVi3iAAA9QLQZwU43PELlvR5V/eJgyyE46tO0VY+Ws8 Uf+MnQNZXOxN/QM5lsDjdD0vKWG8/vrqmPtTeje0XRQgXZJGY7yBK/hf5NNDg/CsRQ UyJ53n8UIhzx/6FdkdThfq3s0RaKR9l/JydpNRjuuS8JnFopfrB5GrsQJ/IL+5mZw7 7ATgkP3A9gBlHeWdXymNd5dTPXOHrCBzah9i3m8BfykcHPqFHWMAFCF7YmbPu/Yk1h XLdz76MbLuvww== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4888Kc4x4JzyQ5; Fri, 31 Jan 2020 08:41:08 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA4.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 31 Jan 2020 08:41:08 +0100 From: To: kaname nishizuka , "dots@ietf.org" Thread-Topic: DOTS Telemetry: URI Path Thread-Index: AdXSA4rBzLMvgmnTQFWFKSY1yB+Z8QF2A9exAApgW9A= Date: Fri, 31 Jan 2020 07:41:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031414366@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303140D0DC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93303141357C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <70510b36-aac4-db69-c88c-3204894f92c0@nttv6.jp> In-Reply-To: <70510b36-aac4-db69-c88c-3204894f92c0@nttv6.jp> 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_787AE7BB302AE849A7480A190F8B933031414366OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS Telemetry: URI Path 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, 31 Jan 2020 07:41:14 -0000 --_000_787AE7BB302AE849A7480A190F8B933031414366OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kaname, Please see inline. Cheers, Med De : kaname nishizuka [mailto:kaname@nttv6.jp] Envoy=E9 : vendredi 31 janvier 2020 03:10 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : Re: DOTS Telemetry: URI Path Hi Med, As per the hackathon report of the last IETF, Server to Client telemetry wo= uld require another URI in order to convey asynchronous notification of att= ack-details from a DOTS server. https://datatracker.ietf.org/meeting/106/materials/slides-106-dots-dots-tel= emetry-related-hackathon-activity-report-00 slide 9. I'd like to hear notions whether that is already taken into account or not. [Med] I confirm that we have recorded that issue. The approach to be publis= hed in -01 can be seen at: https://github.com/boucadair/draft-dots-telemetr= y/blob/master/draft-ietf-dots-telemetry-01.txt. This approach does not requ= ire a new uri: a client that is interested to receive pre-mitigation teleme= try will enable an attribute called "server-initiated-telemetry". The serve= r can then send telemetry data to the client using the same uri (/tm). Of course, this design can be challenged. The plan is to work further on th= at part in -02. Second, regarding with machine learning capability of DOTS, we've noticed s= ome costomized feature like a ratio of SYN versus ACK in TCP flag is contri= buting for precise attack detection (in a feature construction process whic= h is for obtaining contributing features from several metrics). At the last meeting, we've discussed that conveying normal metric is alread= y done by IPFIX. But should adding this kind of DDoS dedicated metric be done in IPFIX or DO= TS? [Med]If this is about tweaking the detection machinery, I'm afraid this is = not part of DOTS. We need more discussion to understand the use case. thanks, Kaname On 2020/01/29 23:47, mohamed.boucadair@orange.com wrote: Hi all, We are currently in the process of updating the draft. I'm afraid that we w= ill finaly need to go with more operation path URIs. See inline for more de= tails. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : jeudi 23 janvier 2020 16:41 =C0 : dots@ietf.org; 'kaname nishizuka' Objet : [Dots] DOTS Telemetry: URI Path Hi all, In the current version of the telemetry draft, we are using '/telemetry' fo= r telemetry-related operations. Kaname suggested to define three operation = suffixes for that. I do think that two are sufficient as indicated below: +-------------------------+----------------+ | Operation | Operation Path | +-------------------------+----------------+ | Telemetry Setup | /tm-setup | +-------------------------+----------------+ | Telemetry | /tm | +-------------------------+----------------+ A dedicated uri (/tm-setup) will be used for telemetry setup operations (ba= seline, configuration): see the excerpt below: augment /ietf-signal:dots-signal/ietf-signal:message-type: +--:(telemetry-setup) {dots-telemetry}? | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 | +--rw telemetry-config | | +--rw low-percentile? percentile | | +--rw mid-percentile? percentile | | +--rw high-percentile? percentile | | +--rw unit-config* [unit] | | +--rw unit unit | | +--rw unit-status? Boolean ... | +--rw baseline | +--rw total-pipe-capability* [unit] | | +--rw unit unit | | +--rw pipe? uint64 | +--rw total-traffic-normal-baseline* [unit protocol] | | +--rw unit unit | | +--rw protocol uint8 | | +--rw low-percentile-g? yang:gauge64 | | +--rw mid-percentile-g? yang:gauge64 | | +--rw high-percentile-g? yang:gauge64 | | +--rw peak-g? yang:gauge64 | +--rw total-connection-capacity* [protocol] | +--rw protocol uint8 ... [Med] The current updated tree structure is as follows: augment /ietf-signal:dots-signal/ietf-signal:message-type: +--:(telemetry-setup) {dots-telemetry}? | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 | +--rw telemetry-config | | +--rw measurement-interval? interval | | +--rw measurement-sample? sample | | +--rw low-percentile? percentile | | +--rw mid-percentile? percentile | | +--rw high-percentile? percentile | | +--rw unit-config* [unit] | | +--rw unit unit | | +--rw unit-status? boolean | +--rw total-pipe-capacity* [link-id unit] | | +--rw link-id nt:link-id | | +--rw unit unit | | +--rw pipe? uint64 | +--rw baseline | +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri | +--rw total-traffic-normal-baseline* [unit protocol] | | +--rw unit unit | | +--rw protocol uint8 | | +--rw low-percentile-g? yang:gauge64 | | +--rw mid-percentile-g? yang:gauge64 | | +--rw high-percentile-g? yang:gauge64 | | +--rw peak-g? yang:gauge64 | +--rw total-connection-capacity* [protocol] | +--rw protocol uint8 | +--rw connection? uint64 | +--rw connection-client? uint64 | +--rw embryonic? uint64 | +--rw embryonic-client? uint64 | +--rw connection-ps? uint64 | +--rw connection-client-ps? uint64 | +--rw request-ps? uint64 | +--rw request-client-ps? uint64 | +--rw partial-request-ps? uint64 | +--rw partial-request-client-ps? uint64 The new structure is designed with the following objectives: =B7 Allow a multi-homed client domain to signal the capacity of eac= h interconnection link. =B7 The normal traffic base line can be provided for the overall do= main (an aggregated prefix, or no target-clause included at all) or for spe= cific targets (IP addresses, prefixes) =B7 These parameters can be communicated using the same or distinct= request. Checks on overlapping targets and links are covered. Nevertheless, this design brings some complexity if a request overlaps with= an existing pipe request but a new baseline traffic. We may either go for = an additional uri or maintain one single uri but go with the following desi= gn (which is my favorite): augment /ietf-signal:dots-signal/ietf-signal:message-type: +--:(telemetry-setup) {dots-telemetry}? | +--rw telemetry* [cuid tsid] | +--rw cuid string | +--rw cdid? string | +--rw tsid uint32 | +--rw (setup-type)? | +--:(telemetry-config) | | +--rw measurement-interval? interval | | +--rw measurement-sample? sample | | +--rw low-percentile? percentile | | +--rw mid-percentile? percentile | | +--rw high-percentile? percentile | | +--rw unit-config* [unit] | | +--rw unit unit | | +--rw unit-status? boolean | +--:(pipe) | | +--rw total-pipe-capacity* [link-id unit] | | +--rw link-id nt:link-id | | +--rw unit unit | | +--rw pipe? uint64 | +--:(baseline) | +--rw baseline | +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri | +--rw total-traffic-normal-baseline* [unit protocol] | | +--rw unit unit | | +--rw protocol uint8 | | +--rw low-percentile-g? yang:gauge64 | | +--rw mid-percentile-g? yang:gauge64 | | +--rw high-percentile-g? yang:gauge64 | | +--rw peak-g? yang:gauge64 | +--rw total-connection-capacity* [protocol] | +--rw protocol uint8 | +--rw connection? uint64 | +--rw connection-client? uint64 | +--rw embryonic? uint64 | +--rw embryonic-client? uint64 | +--rw connection-ps? uint64 | +--rw connection-client-ps? uint64 | +--rw request-ps? uint64 | +--rw request-client-ps? uint64 | +--rw partial-request-ps? uint64 Thoughts? While '/tm' can be used for sharing pre-mitigation telemetry data (an excer= pt of the tree is shown below). +--:(telemetry) {dots-telemetry}? +--rw pre-mitigation* [cuid telemetry-id] +--rw cuid string +--rw cdid? string +--rw telemetry-id uint32 +--rw target | +--rw target-prefix* inet:ip-prefix | +--rw target-port-range* [lower-port] | | +--rw lower-port inet:port-number | | +--rw upper-port? inet:port-number | +--rw target-protocol* uint8 | +--rw target-fqdn* inet:domain-name | +--rw target-uri* inet:uri +--ro total-attack-traffic* [unit protocol] | +--ro unit unit | +--ro protocol uint8 | +--ro low-percentile-g? yang:gauge64 | +--ro mid-percentile-g? yang:gauge64 | +--ro high-percentile-g? yang:gauge64 | +--ro peak-g? yang:gauge64 +--ro total-traffic* [unit protocol] ... +--ro attack-detail +--ro vendor-id? uint32 +--ro attack-id? string +--ro attack-name? string +--ro attack-severity? attack-severity +--ro start-time? uint64 +--ro end-time? uint64 +--ro source-count | +--ro low-percentile-g? yang:gauge64 | +--ro mid-percentile-g? yang:gauge64 | +--ro high-percentile-g? yang:gauge64 | +--ro peak-g? yang:gauge64 +--ro top-talker +--ro source-prefix* [source-prefix] +--ro spoofed-status? boolean +--ro source-prefix inet:ip-prefix ... Unless there are objections, we will implement this change in the next iter= ation of the draft. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B933031414366OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kaname,

 

Please see inline.

 

Cheers,

Med

 

De : kaname nishizuka [mailto:kaname@nttv6.jp]
Envoy=E9 : vendredi 31 janvier 2020 03:10
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : Re: DOTS Telemetry: URI Path

 

Hi Med,

As per the hackathon report of the last IETF, Server to Client telemetry wo= uld require another URI in order to convey asynchronous notification of att= ack-details from a DOTS server.
https://datatracker= .ietf.org/meeting/106/materials/slides-106-dots-dots-telemetry-related-hack= athon-activity-report-00
slide 9.
I'd like to hear notions whether that is already taken into account or not.=

[Med] = I confirm that we have recorded that issue. The approach to be published in= -01 can be seen at: https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-do= ts-telemetry-01.txt. This approach does not require a new uri: a client= that is interested to receive pre-mitigation telemetry will enable an attr= ibute called “server-initiated-telemetry”. The server can then send telemetry data to the client using the same uri (= /tm).

Of cou= rse, this design can be challenged. The plan is to work further on that par= t in -02.

Second, regarding with machine learning capability of DOTS, we've noticed s= ome costomized feature like a ratio of SYN versus ACK in TCP flag is contri= buting for precise attack detection (in a feature construction process whic= h is for obtaining contributing features from several metrics).
At the last meeting, we've discussed that conveying normal metric is alread= y done by IPFIX.
But should adding this kind of DDoS dedicated metric be done in IPFIX or DO= TS?

[Med]I= f this is about tweaking the detection machinery, I’m afraid this is = not part of DOTS. We need more discussion to understand the use case.


thanks,
Kaname

On 2020/01/29 23:47, mohamed.boucadair@orange.com wrote:

Hi all,

 

We are currently in the process of updatin= g the draft. I’m afraid that we will finaly need to go with more oper= ation path URIs. See inline for more details.

 

Cheers,

Med

 

De : Dots [mailto:d= ots-bounces@ietf.org] De la part de mohame= d.boucadair@orange.com
Envoy=E9 : jeudi 23 janvier 2020 16:41
=C0 : dots@ietf.org; 'kana= me nishizuka'
Objet : [Dots] DOTS Telemetry: URI Path

 

Hi all,

 

In the current version of the telemetry draft, we are usi= ng ‘/telemetry’ for telemetry-related operations. Kaname sugges= ted to define three operation suffixes for that. I do think that two are sufficient as indicated below:

 

         +---= ----------------------+----------------+

         | Operat= ion            =    | Operation Path |

         +---= ----------------------+----------------+

         | Teleme= try Setup         | /tm-setup =      |

         +---= ----------------------+----------------+

         | Teleme= try            =    | /tm         &nb= sp;  |

         +---= ----------------------+----------------+

 

A dedicated uri (/tm-setup) will be used for telemetry se= tup operations (baseline, configuration): see the excerpt below:

 

  a= ugment /ietf-signal:dots-signal/ietf-signal:message-type:=

  &= nbsp; +--:(telemetry-setup) {dots-telemetry}?

 &n= bsp;  |  +--rw telemetry* [cuid tsid]

 &n= bsp;  |     +--rw cuid    =             string

 &n= bsp;  |     +--rw cdid?    = ;           string=

 &n= bsp;  |     +--rw tsid    =             uint32

 &n= bsp;  |     +--rw telemetry-config=

 &n= bsp;  |     |  +--rw low-percentile? = ;   percentile

 &n= bsp;  |     |  +--rw mid-percentile? = ;   percentile

 &n= bsp;  |     |  +--rw high-percentile?&nbs= p;  percentile

 &n= bsp;  |     |  +--rw unit-config* [unit]<= /span>

 &n= bsp;  |     |     +--rw un= it           unit<= o:p>

 &n= bsp;  |     |     +--rw un= it-status?   Boolean

 &n= bsp;          …

 &n= bsp;  |     +--rw baseline

 &n= bsp;  |        +--rw total-pipe= -capability* [unit]

 &n= bsp;  |        |  +--rw un= it    unit

 &n= bsp;  |        |  +--rw pi= pe?   uint64

 &n= bsp;  |        +--rw total-traf= fic-normal-baseline* [unit protocol]

 &n= bsp;  |        |  +--rw un= it             =     unit

 &n= bsp;  |        |  +--rw pr= otocol           &nb= sp; uint8

 &n= bsp;  |        |  +--rw lo= w-percentile-g?    yang:gauge64

 &n= bsp;  |        |  +--rw mi= d-percentile-g?    yang:gauge64

 &n= bsp;  |        |  +--rw hi= gh-percentile-g?   yang:gauge64

 &n= bsp;  |        |  +--rw pe= ak-g?           &nbs= p;  yang:gauge64

 &n= bsp;  |        +--rw total-conn= ection-capacity* [protocol]

 &n= bsp;  |           &#= 43;--rw protocol          = ;           uint8 &n= bsp;   

 &n= bsp;    …

[Med] = The current updated tree structure is as follows:

 =

=   augment /ietf-signal:dots-signal/ietf-signal:message-ty= pe:

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

=     |  +--rw telemetry* [cuid tsid]

=     |     +--rw cuid&nb= sp;            =       string

=     |     +--rw cdid?&n= bsp;            = ;     string

=     |     +--rw tsid&nb= sp;            =       uint32

=     |     +--rw telemet= ry-config

=     |     |  +--rw= measurement-interval?   interval

=     |     |  +--rw= measurement-sample?     sample

=     |     |  +--rw= low-percentile?         percentile=

=     |     |  +--rw= mid-percentile?         percentile=

=     |     |  +--rw= high-percentile?        percentile

=     |     |  +--rw= unit-config* [unit]

=     |     |  &nbs= p;  +--rw unit        &nbs= p;  unit

=     |     |  &nbs= p;  +--rw unit-status?   boolean

=     |     +--rw total-p= ipe-capacity* [link-id unit]

=     |     |  +--rw= link-id    nt:link-id

=     |     |  +--rw= unit       unit

=     |     |  +--rw= pipe?      uint64

=     |     +--rw baselin= e

=     |       = +--rw target-prefix*        &n= bsp;          inet:ip-prefix

=     |       = +--rw target-port-range* [lower-port]

=     |       = |  +--rw lower-port    inet:port-number=

=     |       = |  +--rw upper-port?   inet:port-number<= o:p>

=     |       = +--rw target-protocol*        =          uint8<= /o:p>

=     |       = +--rw target-fqdn*        &nbs= p;            inet:d= omain-name

=     |       = +--rw target-uri*         = ;             i= net:uri

=     |       = +--rw total-traffic-normal-baseline* [unit protocol]

=     |       = |  +--rw unit        &nbs= p;        unit=

=     |       = |  +--rw protocol        =      uint8

=     |       = |  +--rw low-percentile-g?    yang:gauge64<= /i>

=     |       = |  +--rw mid-percentile-g?    yang:gauge64<= /i>

=     |       = |  +--rw high-percentile-g?   yang:gauge64

=     |       = |  +--rw peak-g?        &= nbsp;     yang:gauge64

=     |       = +--rw total-connection-capacity* [protocol]<= /p>

=     |       =     +--rw protocol      &n= bsp;            = ;  uint8

=     |       =     +--rw connection?      = ;            uint64<= /span>

=     |       =     +--rw connection-client?    &nbs= p;      uint64

=     |       =     +--rw embryonic?      =              ui= nt64

=     |       =     +--rw embryonic-client?     = ;       uint64

=     |       =     +--rw connection-ps?     &n= bsp;         uint64<= o:p>

=     |       =     +--rw connection-client-ps?    &= nbsp;   uint64

=     |       =     +--rw request-ps?      = ;            uint64<= /span>

=     |       =     +--rw request-client-ps?    &nbs= p;      uint64

=     |       =     +--rw partial-request-ps?    &nb= sp;     uint64

 =    |           = +--rw partial-request-client-ps?   uint64=

 =

The ne= w structure is designed with the following objectives:<= /o:p>

=B7&nbs= p;        Allow a multi-homed client d= omain to signal the capacity of each interconnection link.

=B7&nbs= p;        The normal traffic base line= can be provided for the overall domain (an aggregated prefix, or no target= -clause included at all) or for specific targets (IP addresses, prefixes)

=B7&nbs= p;        These parameters can be comm= unicated using the same or distinct request. Checks on overlapping targets = and links are covered.

 =

Nevert= heless, this design brings some complexity if a request overlaps with an ex= isting pipe request but a new baseline traffic. We may either go for an additional uri or maintain one single uri but go with the follow= ing design (which is my favorite):

 =

  augment /ietf-signal:dots-signal/ie= tf-signal:message-type:

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

    |  +--rw telem= etry* [cuid tsid]

    |   &nbs= p; +--rw cuid         &nbs= p;            &= nbsp;   string

    |   &nbs= p; +--rw cdid?          &n= bsp;            = ;  string

    |   &nbs= p; +--rw tsid         &nbs= p;            &= nbsp;   uint32

    |   &nbs= p; +--rw (setup-type)?

    |   &nbs= p;    +--:(telemetry-config)

    |   &nbs= p;    |  +--rw measurement-interval?   in= terval

    |   &nbs= p;    |  +--rw measurement-sample?   = ;  sample

    |   &nbs= p;    |  +--rw low-percentile?   &nb= sp;     percentile

    |   &nbs= p;    |  +--rw mid-percentile?   &nb= sp;     percentile

    |   &nbs= p;    |  +--rw high-percentile?   &n= bsp;    percentile

    |   &nbs= p;    |  +--rw unit-config* [unit]

    |   &nbs= p;    |     +--rw unit  &n= bsp;        unit

    |   &nbs= p;    |     +--rw unit-status? =   boolean

    |   &nbs= p;    +--:(pipe)

    |   &nbs= p;    |  +--rw total-pipe-capacity* [link-id unit]<= /span>

    |   &nbs= p;    |     +--rw link-id  = ;  nt:link-id

    |   &nbs= p;    |     +--rw unit  &n= bsp;    unit

    |   &nbs= p;    |     +--rw pipe?  &= nbsp;   uint64

    |   &nbs= p;    +--:(baseline)

    |   &nbs= p;       +--rw baseline=

    |   &nbs= p;          +--rw target-p= refix*           &nb= sp;       inet:ip-prefix

    |   &nbs= p;          +--rw target-p= ort-range* [lower-port]

    |   &nbs= p;          |  +--rw = lower-port    inet:port-number

    |   &nbs= p;          |  +--rw = upper-port?   inet:port-number

    |   &nbs= p;          +--rw target-p= rotocol*           &= nbsp;     uint8

    |   &nbs= p;          +--rw target-f= qdn*            = ;         inet:domain-name

    |   &nbs= p;          +--rw target-u= ri*            =           inet:uri=

    |   &nbs= p;          +--rw total-tr= affic-normal-baseline* [unit protocol]

    |   &nbs= p;          |  +--rw = unit            = ;     unit

    |   &nbs= p;          |  +--rw = protocol           &= nbsp; uint8

    |   &nbs= p;          |  +--rw = low-percentile-g?    yang:gauge64

    |   &nbs= p;          |  +--rw = mid-percentile-g?    yang:gauge64

    |   &nbs= p;          |  +--rw = high-percentile-g?   yang:gauge64

    |   &nbs= p;          |  +--rw = peak-g?           &n= bsp;  yang:gauge64

    |   &nbs= p;          +--rw total-co= nnection-capacity* [protocol]

    |   &nbs= p;             = +--rw protocol         &nb= sp;           uint8

    |   &nbs= p;             = +--rw connection?         =          uint64

    |   &nbs= p;             = +--rw connection-client?        = ;   uint64

    |   &nbs= p;             = +--rw embryonic?          =          uint64

    |   &nbs= p;             = +--rw embryonic-client?        =     uint64

    |   &nbs= p;             = +--rw connection-ps?        &nb= sp;      uint64

    |   &nbs= p;             = +--rw connection-client-ps?        u= int64

    |   &nbs= p;             = +--rw request-ps?          = ;        uint64

    |   &nbs= p;             = +--rw request-client-ps?        = ;   uint64

    |   &nbs= p;             = +--rw partial-request-ps?       &nbs= p;  uint64

Though= ts?

 

While ‘/tm’ can be used for sharing pre-mitig= ation telemetry data (an excerpt of the tree is shown below).

 

 &n= bsp;  +--:(telemetry) {dots-telemetry}?

 &n= bsp;     +--rw pre-mitigation* [cuid telemetry-id]<= /span>

 &n= bsp;        +--rw cuid  &n= bsp;            = ;        string

 &n= bsp;        +--rw cdid?  &= nbsp;           &nbs= p;       string

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

 &n= bsp;        +--rw target=

 &n= bsp;        |  +--rw target-pre= fix*       inet:ip-prefix

 &n= bsp;        |  +--rw target-por= t-range* [lower-port]

 &n= bsp;        |  |  +--rw lo= wer-port    inet:port-number

 &n= bsp;        |  |  +--rw up= per-port?   inet:port-number

 &n= bsp;        |  +--rw target-pro= tocol*     uint8

 &n= bsp;        |  +--rw target-fqd= n*         inet:domain-name<= o:p>

 &n= bsp;        |  +--rw target-uri= *          inet:uri

 &n= bsp;        +--ro total-attack-traff= ic* [unit protocol]

 &n= bsp;        |  +--ro unit =             &nb= sp;   unit

 &n= bsp;        |  +--ro protocol&n= bsp;            uint= 8

 &n= bsp;        |  +--ro low-percen= tile-g?    yang:gauge64

 &n= bsp;        |  +--ro mid-percen= tile-g?    yang:gauge64

 &n= bsp;        |  +--ro high-perce= ntile-g?   yang:gauge64

 &n= bsp;        |  +--ro peak-g?&nb= sp;            = yang:gauge64

 &n= bsp;        +--ro total-traffic* [un= it protocol]

 &n= bsp;        …

 &n= bsp;        +--ro attack-detail

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

 &n= bsp;           +--ro = attack-id?         string

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

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

 &n= bsp;           +--ro = start-time?        uint64

 &n= bsp;           +--ro = end-time?          uint64

 &n= bsp;           +--ro = source-count

 &n= bsp;           |  &#= 43;--ro low-percentile-g?    yang:gauge64<= /p>

 &n= bsp;           |  &#= 43;--ro mid-percentile-g?    yang:gauge64<= /p>

 &n= bsp;           |  &#= 43;--ro high-percentile-g?   yang:gauge64

 &n= bsp;           |  &#= 43;--ro peak-g?          =     yang:gauge64

 &n= bsp;           +--ro = top-talker

 &n= bsp;            = ;  +--ro source-prefix* [source-prefix]

 &n= bsp;            = ;     +--ro spoofed-status?    =         boolean

 &n= bsp;            = ;     +--ro source-prefix    &n= bsp;         inet:ip-prefix<= o:p>

 &n= bsp;            = ;  …

 

Unless there are objections, we will implement this chang= e in the next iteration of the draft.

 

Cheers,

Med

 

--_000_787AE7BB302AE849A7480A190F8B933031414366OPEXCAUBMA2corp_-- From nobody Fri Jan 31 06:51:36 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 464DE12007C; Fri, 31 Jan 2020 06:51:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158048229416.21195.16114328651657501634@ietfa.amsl.com> Date: Fri, 31 Jan 2020 06:51:34 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-01.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: Fri, 31 Jan 2020 14:51:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Filename : draft-ietf-dots-telemetry-01.txt Pages : 70 Date : 2020-01-31 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. This document 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-01 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 Fri Jan 31 07:17:41 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B382F120846 for ; Fri, 31 Jan 2020 07:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiBNb29wEzpA for ; Fri, 31 Jan 2020 07:17:39 -0800 (PST) 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 AF1BC120844 for ; Fri, 31 Jan 2020 07:17:38 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 488LSK3ZFHzCr9n for ; Fri, 31 Jan 2020 16:17:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1580483857; bh=wKQhE61dUTM5NXO515chXC10Gltb4uEzLFvtFmxWbeg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jNjoyI+ujxMkSWtoSUMWGlhC4ta0Eo9p/ZkhTttTYjX1w3zZBTDdUrAWjro4OZFH8 vk2Vrfcg8JhoED6U9xW0DVu3WhmBZUcym3p4RN7EaqHvPSCryijQ93U51b7stYfdeh qjmOC+PXsrvaC7jsCREq1+rcjxZ7mkgomczvcBDNO1morNQwaMTUxSxRoYoN06UZhN Lu3HiGwa3tbOQCEnML7LNjx0zQYmLkEb/KkskWnQymm9yFBCOgqG60nmHKKvINMqLq WZtP9LAIS0vRAw3/C2ody1k3L09i5PRP5UortGSDjIqCOUnPf9CnbAq4WGoVhg2+AH fqdcBSxoHum2w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 488LSK39jFzDq7P for ; Fri, 31 Jan 2020 16:17:37 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup ([fe80::193b:bc32:1ad3:362d%21]) with mapi id 14.03.0468.000; Fri, 31 Jan 2020 16:17:37 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt Thread-Index: AQHV2EXz9yDIgoBiC0qPIDVW/PbWkKgE4JlQ Date: Fri, 31 Jan 2020 15:17:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303141473A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158048229416.21195.16114328651657501634@ietfa.amsl.com> In-Reply-To: <158048229416.21195.16114328651657501634@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-01.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 15:17:41 -0000 Hi all,=20 We prepared with Tiru a major revision of the telemetry draft. A diff is pr= ovided below to track the changes. We will now focus on sections 7 and 8. Please review and share comments. Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: vendredi 31 janvier 2020 15:52 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Filename : draft-ietf-dots-telemetry-01.txt > Pages : 70 > Date : 2020-01-31 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal DDoS attack > mitigation. > This document 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-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-01 >=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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots