From nobody Tue Sep 1 01:07:04 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5323A0D86 for ; Tue, 1 Sep 2020 01:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 xgLKboIPcQ21 for ; Tue, 1 Sep 2020 01:07:02 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0787A3A0D8A for ; Tue, 1 Sep 2020 01:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1598947621; 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=ZQo19cOecX9ABPj8Jl7SM6gMFoi4a1FwCZT6UPEQnu8=; b=cZVFsiPkYCJ3mCUvNotm2VHVxloqbfc9l8WZegS2jfdqNIVTLNw7ZCKXWBloxt+IaloKJL XKWSjS8EF0S6eBCTtIS+0fqlR7Z8cvUgxzY52g7aBIfhc0VCYwgiJtV4NyqXdwJUoZ8Rvx CrFco9JqMGo/04PJAX+clVOrLPeqrOA= Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-315-rw40IYJrNU-Yu47NKXL0Cw-1; Tue, 01 Sep 2020 04:05:17 -0400 X-MC-Unique: rw40IYJrNU-Yu47NKXL0Cw-1 Received: from MWHPR16MB1535.namprd16.prod.outlook.com (2603:10b6:320:27::22) by MW2PR16MB2187.namprd16.prod.outlook.com (2603:10b6:907:12::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.24; Tue, 1 Sep 2020 08:05:15 +0000 Received: from MWHPR16MB1535.namprd16.prod.outlook.com ([fe80::2c6f:d09b:e22a:4a47]) by MWHPR16MB1535.namprd16.prod.outlook.com ([fe80::2c6f:d09b:e22a:4a47%11]) with mapi id 15.20.3326.025; Tue, 1 Sep 2020 08:05:15 +0000 From: "Konda, Tirumaleswar Reddy" To: Valery Smyslov , "dots@ietf.org" CC: "dots-chairs@ietf.org" , H Y , "draft-hayashi-dots-telemetry-use-cases@ietf.org" Thread-Topic: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases-00 Thread-Index: AdZ8QgawAJWB9ERrSp2Zb590Qj6oAwD9FfBw Date: Tue, 1 Sep 2020 08:05:14 +0000 Message-ID: References: <0be401d67c45$d4381080$7ca83180$@smyslov.net> In-Reply-To: <0be401d67c45$d4381080$7ca83180$@smyslov.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action x-originating-ip: [49.37.200.126] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5650bb91-4da9-4c89-7ab2-08d84e4dc237 x-ms-traffictypediagnostic: MW2PR16MB2187: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gCZiEtZ25dPu3995eCO7xBfpWGidzzWOzsn8r17jvQ3ysbXVfqQACzQ7VDn3gkIn0z2whpOXdy08x1LprTfXAWehSt7zIkvsvfHoXYs6Mr0+3YyyB4EBPMSB9BXAEmct9QJsurQ9TIpzb53Uhp2xOXITTGoib28SNRe+hjoVulI6faN4sUviWcWNLrBa9RETlhMm56t0Y0pPjRhC7Yb6Y+nSaGUpUhNdz3JqJQI8ZG2+f2rrm1Hk0jrFMEJSPXL4GlNNRgjX12P7ucCwGQcbuilvZjSGw9wmnhqOXWzH/SNlZKk0JgIRbINV9xBUELMxdDMQQpI80ImeaFH6R1jJpRWu7ZbB/Npu5XozU0wMSpEWwKZxOVFlWaiWJsIrtqJR+5kt47W6k5lviVTf9wAMvXQKEUA51uNLmLl9Ft+4LH/9Cl21sIuF/MpZv1meCZHOYkt5Ei9qYc1MLaNvi8laAgWA6cbNB6yWEJryaorHjdE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR16MB1535.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(366004)(32952001)(4326008)(33656002)(7696005)(186003)(76116006)(53546011)(55016002)(26005)(6506007)(64756008)(8936002)(66946007)(52536014)(86362001)(5660300002)(66476007)(66556008)(8676002)(66446008)(71200400001)(83380400001)(9686003)(316002)(966005)(110136005)(478600001)(2906002)(54906003)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: t82VCkoB5HRHpMp3WNExZ5kMczJRVrjTAeiRpxoPbQv3zYo8Btd9/S7o4SKXW2ljcFo5ymTXdHGKVMQ5FKILeAxR67WoydmVuSUo9zfBPvWFcHc4E2nzoRN5Jc1YX0pD9+oFSQwMNkgumasWPOGXFNFa2VFSOwtmsne0EabnjJxUV5c99JDP3cVR3MBLyvvTfzkVPvspx2HUmVJP362Dw9UfWWTa1Sjfqjfb5aHZhZ3MHZSrvJvaRwu2XKDF8r3e8vUR52TsfJt7Cg/Wvh6pr7au5jgbAYE1so4ofbyPy2ht9G9qWzeHN+Mg8T22taWs7JJ6ea9+MkmS1LC2DGEi8DBVrnfL5hyDBVY6Akvtuz+HqwrcG32eY+khACof6Jst6z86S+ScIcvhFbg1TwfcZf2WuwZ6Op3KjlTPsg3jeVsDf/iMwzZs1zhSJ7yTJ+lqaAik3k8IDjmOLUNPtKjWldvBD24LgmhABlxY8h7V44QxPlKAiCZHK/WKQaS8QFTRrZzJPb0Qsr5inBhoYXQViLayi93oxMtdP51Pbc2C0uba49xcSaoSGd4Bcs8XBnFjgI4cImpwC92v1mO/vWiyUrKSaR7gmkl/nw4mHX7Ku5n/w2mFceZg62tfNr8JJTCwTUE5Xs+1jOEjZI5PLHcWKA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR16MB1535.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5650bb91-4da9-4c89-7ab2-08d84e4dc237 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 08:05:14.8580 (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: T7OWHnEi3LSyqL9YaJYVpLq6CPMMvHRiU80KJvdklN9ermEYR4T/w3nmqzkoKrrggG24BKiU3kbbxSioY4jpZ4Ql6eRGPIiDLqyfNn8Wne/YEjVD5Ss5QP12pMX5vmZ6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR16MB2187 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA40A35 smtp.mailfrom=tirumaleswarreddy_konda@mcafee.com X-Mimecast-Spam-Score: 0.003 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases-00 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, 01 Sep 2020 08:07:04 -0000 I support adoption of this draft (prefer option 1). -Tiru > -----Original Message----- > From: Dots On Behalf Of Valery Smyslov > Sent: Thursday, August 27, 2020 1:14 PM > To: dots@ietf.org > Cc: dots-chairs@ietf.org; H Y ; draft-hayashi- > dots-telemetry-use-cases@ietf.org > Subject: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cas= es- > 00 >=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, >=20 > after discussion with Yuhei we decided to issue a call for adoption of dr= aft- > hayashi-dots-telemetry-use-cases-00 as a WG document. >=20 > Note, that the chairs have an opinion, that the DOTS WG has already > published quite a lot of informational documents, describing DOTS > requirements, architecture, use cases. > We think that having one more auxiliary document that describes use cases > only for an optional feature of DOTS > (telemetry) is not fully justified and it's probably better to merge tele= metry > use cases draft with telemetry I-D. > We think that for implementers it's generally easier to look into a singl= e > document, than to find a separate one describing use cases. Another > consideration is that if a separate document is adopted, then the process= ing > of the telemetry I-D will probably have to be slow down until the telemet= ry > use cases draft is ready, so that they are sent to publication together (= in this > case the telemetry draft will have a steady reference to RFC and not to = I-D). >=20 > On the other hand, discussion on last DOTS meeting and on the list indica= ted > that quite a lot of people in the WG prefer to have telemetry use cases a= s a > separate document, instead of merging it with the telemetry draft. The > concerns were expressed that telemetry draft is already a long document > and authors don't want to make it longer. >=20 > So, this message start a two weeks call for adoption of > draft-hayashi-dots-telemetry-use-cases-00 that will end 11 September. > Please, respond to the list with your preference among 2 options: >=20 > 1. Adopt this draft as a separate document describing DOTS telemetry use > cases. > 2. Don't adopt this draft and merge its content into the draft-ietf-dots- > telemetry instead. >=20 > We'll be very much appreciated if you also give reasoning for your choice= . >=20 > Regards, > Frank & Valery. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Sep 1 01:39:44 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EE73A0DF3; Tue, 1 Sep 2020 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjMExYSptxA4; Tue, 1 Sep 2020 01:39:41 -0700 (PDT) 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 212EF3A0DD4; Tue, 1 Sep 2020 01:39:41 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 268EEE61B824B1B8A6AA; Tue, 1 Sep 2020 09:39:39 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 1 Sep 2020 09:39:38 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 1 Sep 2020 16:39:36 +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.1913.007; Tue, 1 Sep 2020 16:39:36 +0800 From: "Panwei (William)" To: Valery Smyslov , "dots@ietf.org" CC: "dots-chairs@ietf.org" , H Y , "draft-hayashi-dots-telemetry-use-cases@ietf.org" Thread-Topic: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases-00 Thread-Index: AdZ8QgawAJWB9ERrSp2Zb590Qj6oAwD+VTkw Date: Tue, 1 Sep 2020 08:39:36 +0000 Message-ID: References: <0be401d67c45$d4381080$7ca83180$@smyslov.net> In-Reply-To: <0be401d67c45$d4381080$7ca83180$@smyslov.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.99.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases-00 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, 01 Sep 2020 08:39:43 -0000 +1 support for option 1. Regards & Thanks! Wei Pan -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Valery Smyslov Sent: Thursday, August 27, 2020 3:44 PM To: dots@ietf.org Cc: dots-chairs@ietf.org; H Y ; draft-hayashi-dot= s-telemetry-use-cases@ietf.org Subject: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases= -00 Hi, after discussion with Yuhei we decided to issue a call for adoption of draf= t-hayashi-dots-telemetry-use-cases-00 as a WG document. Note, that the chairs have an opinion, that the DOTS WG has already publish= ed quite a lot of informational documents, describing DOTS requirements, ar= chitecture, use cases. We think that having one more auxiliary document that describes use cases o= nly for an optional feature of DOTS (telemetry) is not fully justified and it's probably better to merge teleme= try use cases draft with telemetry I-D.=20 We think that for implementers it's generally easier to look into a single = document, than to find a separate one describing use cases. Another conside= ration is that if a separate document is adopted, then the processing of th= e telemetry I-D will probably have to be slow down until the telemetry use = cases draft is ready, so that they are sent to publication together (in thi= s case the telemetry draft will have a steady reference to RFC and not to = I-D). On the other hand, discussion on last DOTS meeting and on the list indicate= d that quite a lot of people in the WG prefer to have telemetry use cases a= s a separate document, instead of merging it with the telemetry draft. The = concerns were expressed that telemetry draft is already a long document and= authors don't want to make it longer. So, this message start a two weeks call for adoption of draft-hayashi-dots-telemetry-use-cases-00 that will end 11 September.=20 Please, respond to the list with your preference among 2 options: 1. Adopt this draft as a separate document describing DOTS telemetry use ca= ses. 2. Don't adopt this draft and merge its content into the draft-ietf-dots-te= lemetry instead. We'll be very much appreciated if you also give reasoning for your choice. Regards, Frank & Valery. _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Sep 2 21:02:00 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CEC3A0EFA; Wed, 2 Sep 2020 21:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSmdIMMDKxTg; Wed, 2 Sep 2020 21:01:56 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9503A0EFB; Wed, 2 Sep 2020 21:01:54 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee75f506aa5178-f24a3; Thu, 03 Sep 2020 12:01:43 +0800 (CST) X-RM-TRANSID: 2ee75f506aa5178-f24a3 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.53.240]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75f506aa55cc-ef243; Thu, 03 Sep 2020 12:01:43 +0800 (CST) X-RM-TRANSID: 2ee75f506aa55cc-ef243 From: "SuLi" To: Cc: , , , References: <202009031147246061441@chinamobile.com> In-Reply-To: <202009031147246061441@chinamobile.com> Date: Thu, 3 Sep 2020 12:01:42 +0800 Message-ID: <004d01d681a6$eefc6180$ccf52480$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01D681E9.FD1FA180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdaBpPBJGJO5W1gQS/qeUebW+HvusQAAN+ow Content-Language: zh-cn Archived-At: Subject: Re: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases-00 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, 03 Sep 2020 04:01:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004E_01D681E9.FD1FA180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support adoption of this draft (prefer option 1). =20 Best Regards! Su Li(=E7=B2=9F=E6=A0=97) =20 From: Valery Smyslov =20 Date: 2020-08-27 15:43 To: dots@ietf.org CC: dots-chairs ; H Y = ; = draft-hayashi-dots-telemetry-use-cases = =20 Subject: [Dots] Call for adoption of = draft-hayashi-dots-telemetry-use-cases-00 Hi, =20 after discussion with Yuhei we decided to issue a call for adoption=20 of draft-hayashi-dots-telemetry-use-cases-00 as a WG document. =20 Note, that the chairs have an opinion, that the DOTS WG has already published quite a lot of informational documents,=20 describing DOTS requirements, architecture, use cases. We think that having one more auxiliary document that describes use cases only for an optional feature of DOTS (telemetry) is not fully justified and it's probably better to merge telemetry use cases draft with telemetry I-D.=20 We think that for implementers it's generally easier to look into=20 a single document, than to find a separate one describing use cases. Another consideration is that=20 if a separate document is adopted, then the processing of=20 the telemetry I-D will probably have to be slow down until the telemetry = use cases=20 draft is ready, so that they are sent to publication together (in this case the telemetry draft will have a steady reference to RFC = and not to I-D). =20 On the other hand, discussion on last DOTS meeting and=20 on the list indicated that quite a lot of people in the WG=20 prefer to have telemetry use cases as a separate=20 document, instead of merging it with the telemetry draft. The concerns were expressed that telemetry draft is already a long document and authors=20 don't want to make it longer. =20 So, this message start a two weeks call for adoption of=20 draft-hayashi-dots-telemetry-use-cases-00 that will end 11 September.=20 Please, respond to the list with your preference among 2 options: =20 1. Adopt this draft as a separate document describing DOTS telemetry use = cases. 2. Don't adopt this draft and merge its content into the = draft-ietf-dots-telemetry instead. =20 We'll be very much appreciated if you also give reasoning for your = choice. =20 Regards, Frank & Valery. =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_004E_01D681E9.FD1FA180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I support adoption of this draft (prefer option = 1).

 

Best Regards!

Su Li(=E7=B2=9F=E6=A0=97)

 

F= rom:&= nbsp;Valery = Smyslov

D= ate:&= nbsp;2020-08-27 15:43

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

S= ubject:&= nbsp;[Dots] Call for adoption of = draft-hayashi-dots-telemetry-use-cases-00

Hi,

 

after discussion with Yuhei we decided to = issue a call for adoption

of draft-hayashi-dots-telemetry-use-cases-00 = as a WG document.

 

Note, that the chairs have an opinion, that = the DOTS WG has

already published quite a lot of = informational documents,

describing DOTS requirements, architecture, = use cases.

We think that having one more auxiliary = document that

describes use cases only for an optional = feature of DOTS

(telemetry) is not fully justified and it's = probably better

to merge telemetry use cases draft with = telemetry I-D.

We think that for implementers it's = generally easier to look into

a single document, than to find a separate = one

describing use cases. Another consideration = is that

if a separate document is adopted, then the = processing of

the telemetry I-D will probably have to be = slow down until the telemetry use cases =

draft is ready, so that they are sent to = publication together

(in this case the telemetry draft will  = have a steady reference to RFC and

not to = I-D).

 

On the other hand, discussion on last DOTS = meeting and

on the list indicated that quite a lot of = people in the WG

prefer to have telemetry use cases as a = separate

document, instead of merging it with the = telemetry

draft. The concerns were expressed that = telemetry

draft is already a long document and authors =

don't want to make it = longer.

 

So, this message start a two weeks call for = adoption of

draft-hayashi-dots-telemetry-use-cases-00 = that will end 11 September.

Please, respond to the list with your = preference among 2 options:

 

1. Adopt this draft as a separate document = describing DOTS telemetry use cases.

2. Don't adopt this draft and merge its = content into the draft-ietf-dots-telemetry = instead.

 

We'll be very much appreciated if you also = give reasoning for your choice.

 

Regards,

Frank & = Valery.

 

_____________________________________________= __

Dots mailing = list

Dots@ietf.org

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

 

------=_NextPart_000_004E_01D681E9.FD1FA180-- From nobody Fri Sep 4 00:44:19 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7D3A0C1D; Fri, 4 Sep 2020 00:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyKjkwrumDQk; Fri, 4 Sep 2020 00:44:15 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 41F913A0938; Fri, 4 Sep 2020 00:44:11 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.15]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee95f51f040dc8-0c80f; Fri, 04 Sep 2020 15:44:00 +0800 (CST) X-RM-TRANSID: 2ee95f51f040dc8-0c80f X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.53.240]) by rmsmtp-syy-appsvr08-12008 (RichMail) with SMTP id 2ee85f51f03f058-9b55b; Fri, 04 Sep 2020 15:44:00 +0800 (CST) X-RM-TRANSID: 2ee85f51f03f058-9b55b From: "SuLi" To: Cc: , , , References: <202009031147246061441@chinamobile.com> In-Reply-To: Date: Fri, 4 Sep 2020 15:43:57 +0800 Message-ID: <005701d6828f$262c25d0$72847170$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01D682D2.344F65D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdaBpPBJGJO5W1gQS/qeUebW+HvusQAAN+owADpS8+A= Content-Language: zh-cn Archived-At: Subject: Re: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases-00 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, 04 Sep 2020 07:44:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0058_01D682D2.344F65D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 I support adoption of this draft (prefer option 1). =20 Best Regards! Su Li(=E7=B2=9F=E6=A0=97) =20 From: Valery Smyslov =20 Date: 2020-08-27 15:43 To: dots@ietf.org CC: dots-chairs ; H Y = ; = draft-hayashi-dots-telemetry-use-cases = =20 Subject: [Dots] Call for adoption of = draft-hayashi-dots-telemetry-use-cases-00 Hi, =20 after discussion with Yuhei we decided to issue a call for adoption=20 of draft-hayashi-dots-telemetry-use-cases-00 as a WG document. =20 Note, that the chairs have an opinion, that the DOTS WG has already published quite a lot of informational documents,=20 describing DOTS requirements, architecture, use cases. We think that having one more auxiliary document that describes use cases only for an optional feature of DOTS (telemetry) is not fully justified and it's probably better to merge telemetry use cases draft with telemetry I-D.=20 We think that for implementers it's generally easier to look into=20 a single document, than to find a separate one describing use cases. Another consideration is that=20 if a separate document is adopted, then the processing of=20 the telemetry I-D will probably have to be slow down until the telemetry = use cases=20 draft is ready, so that they are sent to publication together (in this case the telemetry draft will have a steady reference to RFC = and not to I-D). =20 On the other hand, discussion on last DOTS meeting and=20 on the list indicated that quite a lot of people in the WG=20 prefer to have telemetry use cases as a separate=20 document, instead of merging it with the telemetry draft. The concerns were expressed that telemetry draft is already a long document and authors=20 don't want to make it longer. =20 So, this message start a two weeks call for adoption of=20 draft-hayashi-dots-telemetry-use-cases-00 that will end 11 September.=20 Please, respond to the list with your preference among 2 options: =20 1. Adopt this draft as a separate document describing DOTS telemetry use = cases. 2. Don't adopt this draft and merge its content into the = draft-ietf-dots-telemetry instead. =20 We'll be very much appreciated if you also give reasoning for your = choice. =20 Regards, Frank & Valery. =20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0058_01D682D2.344F65D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

I support adoption of this draft (prefer option = 1).

 

Best Regards!

Su Li(=E7=B2=9F=E6=A0=97)

 

F= rom:&= nbsp;Valery = Smyslov

D= ate:&= nbsp;2020-08-27 15:43

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

S= ubject:&= nbsp;[Dots] Call for adoption of = draft-hayashi-dots-telemetry-use-cases-00

Hi,

 

after discussion with Yuhei we decided to = issue a call for adoption

of draft-hayashi-dots-telemetry-use-cases-00 = as a WG document.

 

Note, that the chairs have an opinion, that = the DOTS WG has

already published quite a lot of = informational documents,

describing DOTS requirements, architecture, = use cases.

We think that having one more auxiliary = document that

describes use cases only for an optional = feature of DOTS

(telemetry) is not fully justified and it's = probably better

to merge telemetry use cases draft with = telemetry I-D.

We think that for implementers it's = generally easier to look into

a single document, than to find a separate = one

describing use cases. Another consideration = is that

if a separate document is adopted, then the = processing of

the telemetry I-D will probably have to be = slow down until the telemetry use cases =

draft is ready, so that they are sent to = publication together

(in this case the telemetry draft will  = have a steady reference to RFC and

not to = I-D).

 

On the other hand, discussion on last DOTS = meeting and

on the list indicated that quite a lot of = people in the WG

prefer to have telemetry use cases as a = separate

document, instead of merging it with the = telemetry

draft. The concerns were expressed that = telemetry

draft is already a long document and authors =

don't want to make it = longer.

 

So, this message start a two weeks call for = adoption of

draft-hayashi-dots-telemetry-use-cases-00 = that will end 11 September.

Please, respond to the list with your = preference among 2 options:

 

1. Adopt this draft as a separate document = describing DOTS telemetry use cases.

2. Don't adopt this draft and merge its = content into the draft-ietf-dots-telemetry = instead.

 

We'll be very much appreciated if you also = give reasoning for your choice.

 

Regards,

Frank & = Valery.

 

_____________________________________________= __

Dots mailing = list

Dots@ietf.org

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

 

------=_NextPart_000_0058_01D682D2.344F65D0-- From nobody Sun Sep 13 23:23: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 AF75B3A0C1B for ; Sun, 13 Sep 2020 23:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QAS-zKoI2fNw for ; Sun, 13 Sep 2020 23:23:30 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF493A0C10 for ; Sun, 13 Sep 2020 23:23:30 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4BqbsD5VSLz8tNW for ; Mon, 14 Sep 2020 08:23:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1600064608; bh=6p1BLKyv6Zo0UTxa274DTxXYa+HaXHgqv/NFTVH3IpE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UR3w/C5OOdFc1ZHSwjN+fe+e1gYfy0ABVRMF9j7NG/ZfXJbw1lQNgmMBgfjP5+aS/ l/JAseoMb5p/N2l4gQoLkTShZDcR9ICCcDCFWkGJOh7JvvKL16XmFWzkcVBD51mJCN l8AcwYcHZoMFs9qWDVA4tErZW6J/hinnzB8CBprKZtqGBzjTJkpDYn/tr9so1fzHT/ 2evATs2mFqueuMI9aPIV5Fpi+iThA58fjU8YI9ttsAnC2T9j7Esjofs/XM5qjl7ftO BDtNxgSdIXtSDq4yh7sA7E60a8CEBV/+31NJfRulQ9kypqmpL9B8vgktUKFqdnXnQC u42fX4Ay/+TJw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4BqbsD4mrPzBrLH for ; Mon, 14 Sep 2020 08:23:28 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: AUTH48 [RE]: RFC 8909 NOW AVAILABLE Thread-Index: AQHWiIxkC7jxu6ZB0UGuaPFFumYLwqlnoBIggAANVQA= Date: Mon, 14 Sep 2020 06:23:28 +0000 Message-ID: <3213_1600064608_5F5F0C60_3213_84_1_787AE7BB302AE849A7480A190F8B93303153FD38@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200911223658.CB90FF4077E@rfc-editor.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dots] TR: AUTH48 [RE]: RFC 8909 NOW AVAILABLE X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 06:23:33 -0000 SGkgYWxsLCANCg0KSSBmb3Jnb3QgdG8gY2MgdGhlIGxpc3QgYXMgdGhlc2UgYXJlIHJlcXVpcmVk IGNoYW5nZXMgdG8gcmVmbGVjdCB0aGUgV0cgZGVjaXNpb24gdG8gdXBkYXRlIHJmYzg3ODIuDQoN CkNoZWVycywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEJPVUNB REFJUiBNb2hhbWVkIFRHSS9PTE4gDQpFbnZvecOpwqA6IGx1bmRpIDE0IHNlcHRlbWJyZSAyMDIw IDA3OjUyDQrDgMKgOiAncmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZycgPHJmYy1lZGl0b3JAcmZj LWVkaXRvci5vcmc+OyBrYW5hbWVAbnR0djYuanA7IGtvbmR0aXJAZ21haWwuY29tOyBuYWdhdGFA bGVwaWR1bS5jby5qcA0KQ2PCoDogZG90cy1hZHNAaWV0Zi5vcmc7IGRvdHMtY2hhaXJzQGlldGYu b3JnOyBmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tDQpPYmpldMKgOiBSRTogQVVUSDQ4IFtSRV06 IFJGQyA4OTA5IDxkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci1jb250cm9sLTA3LnR4dD4g Tk9XIEFWQUlMQUJMRQ0KDQpEZWFyIFJGQyBFZGl0b3IsIGFsbCwgDQoNClRoZSBlZGl0cyBsb29r IGdvb2QuIEJlbG93IHNvbWUgY29tbWVudHM6DQoNCigxKSBzL1tET1RTLUFSQ0hdL1tSRkM4ODEx XQ0KDQooMikgV2hpbGUgdGhpcyBkb2N1bWVudCB3YXMgaW4gdGhlIGVkaXRpbmcgcXVldWUsIHdl IGRpc2NvdmVyZWQgYW4gaXNzdWUgd2l0aCBSRkM4NzgyIHRoYXQgaW1wbGllcyBzb21lIG1vZGlm aWNhdGlvbnMgdG8gdGhpcyBkcmFmdDogDQoNCmEuIFJlcGxhY2UgdGhyb3VnaCB0aGUgZG9jdW1l bnQgUkZDODc4MiB3aXRoIGRyYWZ0LWlldGYtZG90cy1yZmM4NzgyLWJpcyBiLiBVcGRhdGUgdGhl IHRyZWUgc3RydWN0dXJlIGluIFNlY3Rpb24gMy4yLjIuMSBhcyBmb2xsb3dzOg0KDQpPTEQ6DQog ICBtb2R1bGU6IGlldGYtZG90cy1zaWduYWwtY29udHJvbA0KICAgICBhdWdtZW50IC9pZXRmLXNp Z25hbDpkb3RzLXNpZ25hbC9pZXRmLXNpZ25hbDptZXNzYWdlLXR5cGUNCiAgICAgICAgICAgICAv aWV0Zi1zaWduYWw6bWl0aWdhdGlvbi1zY29wZS9pZXRmLXNpZ25hbDpzY29wZToNCiAgICAgICAr LS1ydyBhY2wtbGlzdCogW2FjbC1uYW1lXSB7Y29udHJvbC1maWx0ZXJpbmd9Pw0KICAgICAgICAg ICstLXJ3IGFjbC1uYW1lDQogICAgICAgICAgfCAgICAtPiAvaWV0Zi1kYXRhOmRvdHMtZGF0YS9k b3RzLWNsaWVudC9hY2xzL2FjbC9uYW1lDQogICAgICAgICAgKy0tcncgYWN0aXZhdGlvbi10eXBl PyAgIGlldGYtZGF0YTphY3RpdmF0aW9uLXR5cGUNCg0KTkVXOiANCm1vZHVsZTogaWV0Zi1kb3Rz LXNpZ25hbC1jb250cm9sDQogIGF1Z21lbnQtc3RydWN0dXJlIC9pZXRmLXNpZ25hbDpkb3RzLXNp Z25hbC9pZXRmLXNpZ25hbDptZXNzYWdlLXR5cGUNCiAgICAgICAgICAgICAgICAgICAgL2lldGYt c2lnbmFsOm1pdGlnYXRpb24tc2NvcGUvaWV0Zi1zaWduYWw6c2NvcGU6DQogICAgKy0tIGFjbC1s aXN0KiBbYWNsLW5hbWVdDQogICAgICAgKy0tIGFjbC1uYW1lDQogICAgICAgfCAgICAgICAtPiAv aWV0Zi1kYXRhOmRvdHMtZGF0YS9kb3RzLWNsaWVudC9hY2xzL2FjbC9uYW1lDQogICAgICAgKy0t IGFjdGl2YXRpb24tdHlwZT8gICBpZXRmLWRhdGE6YWN0aXZhdGlvbi10eXBlDQoNCmMuIFVwZGF0 ZSB0aGUgaW1wb3J0cyBpbiBTZWN0aW9uIDMuMi4yLjIuIE5vdGVzOg0KLSBSRkNYWFhYIHdpbGwg YmUgdGhlIG51bWJlciB0byBiZSBhc3NpZ25lZCB0byBkcmFmdC1pZXRmLWRvdHMtcmZjODc4Mi1i aXMpDQotIFJGQyA4NzkxIHRvIGJlIGxpc3RlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuIA0K DQpPTEQ6DQogICAgIGltcG9ydCBpZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwgew0KICAgICAgIHBy ZWZpeCBpZXRmLXNpZ25hbDsNCiAgICAgICByZWZlcmVuY2UNCiAgICAgICAgICJSRkMgODc4Mjog RGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCiAgICAgICAgICAgICAg ICAgICAgU2lnbmFsaW5nIChET1RTKSBTaWduYWwgQ2hhbm5lbCBTcGVjaWZpY2F0aW9uIjsNCiAg ICAgfQ0KDQpORVc6DQogICAgIGltcG9ydCBpZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwgew0KICAg ICAgIHByZWZpeCBpZXRmLXNpZ25hbDsNCiAgICAgICByZWZlcmVuY2UNCiAgICAgICAgICJSRkMg WFhYWDogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCiAgICAgICAg ICAgICAgICAgICAgU2lnbmFsaW5nIChET1RTKSBTaWduYWwgQ2hhbm5lbCBTcGVjaWZpY2F0aW9u IjsNCiAgICAgfQ0KICAgICBpbXBvcnQgaWV0Zi15YW5nLXN0cnVjdHVyZS1leHQgew0KICAgICAg IHByZWZpeCBzeDsNCiAgICAgICByZWZlcmVuY2UNCiAgICAgICAgICJSRkMgODc5MTogWUFORyBE YXRhIFN0cnVjdHVyZSBFeHRlbnNpb25zIjsNCiAgICAgfQ0KDQpkLiBVcGRhdGUgdGhpcyBwYXJ0 IG9mIHRoZSBZQU5HIG1vZHVsZTogDQoNCk9MRDogDQogICAgIGZlYXR1cmUgY29udHJvbC1maWx0 ZXJpbmcgew0KICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAiVGhpcyBmZWF0dXJlIG1lYW5z IHRoYXQgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgaXMgYWJsZQ0KICAgICAgICAgIHRvIG1hbmFn ZSB0aGUgZmlsdGVyaW5nIHJ1bGVzIGNyZWF0ZWQgYnkgdGhlIHNhbWUgRE9UUw0KICAgICAgICAg IGNsaWVudCB1c2luZyB0aGUgRE9UUyBkYXRhIGNoYW5uZWwuIjsNCiAgICAgfQ0KDQogICAgIGF1 Z21lbnQgIi9pZXRmLXNpZ25hbDpkb3RzLXNpZ25hbC9pZXRmLXNpZ25hbDptZXNzYWdlLXR5cGUi DQogICAgICAgICAgICsgIi9pZXRmLXNpZ25hbDptaXRpZ2F0aW9uLXNjb3BlL2lldGYtc2lnbmFs OnNjb3BlIiB7DQogICAgICAgaWYtZmVhdHVyZSBjb250cm9sLWZpbHRlcmluZzsgImNvbnRyb2wt ZmlsdGVyaW5nIjsNCg0KTkVXOg0KICBzeDphdWdtZW50LXN0cnVjdHVyZSAiL2lldGYtc2lnbmFs OmRvdHMtc2lnbmFsL2lldGYtc2lnbmFsOm1lc3NhZ2UtdHlwZSINCiAgICAgICAgICAgICAgICAg ICAgICsgIi9pZXRmLXNpZ25hbDptaXRpZ2F0aW9uLXNjb3BlL2lldGYtc2lnbmFsOnNjb3BlIiB7 DQoNCmUuIHMvU2VjdGlvbiAxMCBvZiBbUkZDODc4Ml0vU2VjdGlvbiAxMSBvZiBbUkZDODc4Ml0N Cg0KVGhhbmsgeW91LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+IERlwqA6IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcgW21haWx0bzpyZmMtZWRp dG9yQHJmYy1lZGl0b3Iub3JnXQ0KPiBFbnZvecOpwqA6IHNhbWVkaSAxMiBzZXB0ZW1icmUgMjAy MCAwMDozNyDDgMKgOiBrYW5hbWVAbnR0djYuanA7IEJPVUNBREFJUiANCj4gTW9oYW1lZCBUR0kv T0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsga29uZHRpckBnbWFpbC5jb207IA0K PiBuYWdhdGFAbGVwaWR1bS5jby5qcCBDY8KgOiByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnOyAN Cj4gZG90cy1hZHNAaWV0Zi5vcmc7IGRvdHMtIGNoYWlyc0BpZXRmLm9yZzsgZnJhbmsueGlhbGlh bmdAaHVhd2VpLmNvbSANCj4gT2JqZXTCoDogQVVUSDQ4IFtSRV06IFJGQyA4OTA5IDxkcmFmdC1p ZXRmLWRvdHMtc2lnbmFsLWZpbHRlci0gDQo+IGNvbnRyb2wtMDcudHh0PiBOT1cgQVZBSUxBQkxF DQo+IA0KPiAqKioqKklNUE9SVEFOVCoqKioqDQo+IA0KPiBVcGRhdGVkIDIwMjAvMDkvMTENCj4g DQo+IFJGQyBBdXRob3Iocyk6DQo+IC0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJbnN0cnVjdGlvbnMg Zm9yIENvbXBsZXRpbmcgQVVUSDQ4IGluIFhNTA0KPiANCj4gVGhpcyBpcyB5b3VyIGxhc3QgY2hh bmNlIHRvIG1ha2UgY2hhbmdlcyB0byB5b3VyIFJGQy10by1iZToNCj4gZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1maWx0ZXItY29udHJvbC0wNy50eHQuDQo+IE9uY2UgdGhlIGRvY3VtZW50IGlzIHB1 Ymxpc2hlZCBhcyBhbiBSRkMsIHdlIHdpbGwgbm90IG1ha2UgY2hhbmdlcy4NCj4gUGxlYXNlIGZv bGxvdyB0aGUgaW5zdHJ1Y3Rpb25zIGJlbG93IHRvIGNvbXBsZXRlIHRoZSBBVVRINDggcHJvY2Vz cy4NCj4gKEZvciBmcmVxdWVudGx5IGFza2VkIHF1ZXN0aW9ucywgcGxlYXNlIHNlZQ0KPiBodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9mYXEvI2F1dGg0OC4pDQo+IA0KPiAxKSBUaGlzIGRvY3Vt ZW50IGlzIGJlaW5nIHByb2Nlc3NlZCB1c2luZyB4bWwycmZjIHYzIHRvb2xzLg0KPiAgICBQbGVh c2UgaGVscCB1cyBieSByZXZpZXdpbmcgYWxsIGZvcm1hdHMgY2FyZWZ1bGx5IGR1cmluZyBBVVRI NDguDQo+ICAgIFRoZSBmb2xsb3dpbmcgZmlsZXMgYXJlIGF2YWlsYWJsZSBmb3IgcmV2aWV3Og0K PiANCj4gICAgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvYXV0aG9ycy9yZmM4OTA5Lmh0bWwN Cj4gICAgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvYXV0aG9ycy9yZmM4OTA5LnBkZg0KPiAg ICBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9hdXRob3JzL3JmYzg5MDkudHh0DQo+IA0KPiAg ICBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9hdXRob3JzL3JmYzg5MDkueG1sDQo+ICAgIChO b3RlOiB5b3UgbWF5IG5lZWQgdG8gdmlldyB0aGUgcGFnZSBzb3VyY2UgdG8gc2F2ZSB0aGUgZmls ZS4pDQo+IA0KPiBOb3RlIHRoYXQgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj4gcHJv dmlkZXMgdG9vbHMgdG8gbWFrZSANCj4gdmFyaW91cyBraW5kcyBvZiBkaWZmIGZpbGVzLiAgV2Ug cHJvdmlkZSB0aGUgZm9sbG93aW5nIGZvciB5b3VyIA0KPiBjb252ZW5pZW5jZS4NCj4gDQo+IENo YW5nZXMgdG8gdGhlIGNvbnRlbnQgYXJlIGJlc3Qgdmlld2FibGUgaW4gdGhlIGZvbGxvd2luZyBk aWZmIGZpbGUgb2YgDQo+IHRoZSB0ZXh0Og0KPiAgICBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9hdXRob3JzL3JmYzg5MDktZGlmZi5odG1sDQo+IA0KPiBDaGFuZ2VzIHRvIHRoZSBYTUwgZmls ZSBhcmUgdmlld2FibGUgaW4gdGhlIGZvbGxvd2luZyBkaWZmIGZpbGUgDQo+IChpbmNsdWRlcyB1 cGRhdGVzIHRvIHRoZSBYTUwgdGFnZ2luZyBhbmQgdGhlIGNvbnRlbnQpOg0KPiAgICBodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9hdXRob3JzL3JmYzg5MDkteG1sZGlmZjEuaHRtbA0KPiANCj4g DQo+IFRoZSBmb2xsb3dpbmcgZmlsZXMgYXJlIHByb3ZpZGVkIHRvIGZhY2lsaXRhdGUgY3JlYXRp b24gb2YgeW91ciBvd24gDQo+IGRpZmYgZmlsZXMgb2YgdGhlIFhNTC4NCj4gDQo+IEluaXRpYWwg WE1MdjMgY3JlYXRlZCB1c2luZyBYTUx2MiBhcyBpbnB1dDoNCj4gICAgaHR0cHM6Ly93d3cucmZj LWVkaXRvci5vcmcvYXV0aG9ycy9yZmM4OTA5Lm9yaWdpbmFsLnYydjMueG1sDQo+IA0KPiBYTUx2 MyBmaWxlIHRoYXQgaXMgYSBiZXN0IGVmZm9ydCB0byBjYXB0dXJlIHYzLXJlbGF0ZWQgZm9ybWF0 IHVwZGF0ZXMgDQo+IG9ubHk6DQo+ICAgIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2F1dGhv cnMvcmZjODkwOS5mb3JtLnhtbA0KPiANCj4gMikgUmV2aWV3IGFuZCByZXNvbHZlIChhcyBuZWNl c3NhcnkpIGFueSBxdWVzdGlvbnMgcmFpc2VkIGJ5IHRoZSBSRkMNCj4gICAgRWRpdG9yLiAgVGhl IHF1ZXN0aW9ucyAoaWYgYW55KSBoYXZlIGJlZW4gaW5jbHVkZWQgaW4gdGhlIFhNTCBmaWxlIA0K PiBhcw0KPiAgICBjb21tZW50cyBtYXJrZWQgPCEtLSBbcmZjZWRdIC4uLiAtLT4gYW5kIHdpbGwg YmUgc2VudCBpbiBhIA0KPiBzdWJzZXF1ZW50IGVtYWlsLg0KPiANCj4gMykgU2VuZCB1cyB5b3Vy IGNoYW5nZXMgb3IgcmVzcG9uZCB3aXRoIHlvdXIgYXBwcm92YWwgZm9yIHB1YmxpY2F0aW9uLg0K PiAgICBQbGVhc2UgdXNlICdSRVBMWSBBTEwnIHNvIHRoYXQgcmZjLWVkaXRvckByZmMtZWRpdG9y Lm9yZyBhbmQgdGhlIA0KPiBwYXJ0aWVzDQo+ICAgIENDJ2VkIG9uIHRoaXMgbWVzc2FnZSByZWNl aXZlIHlvdXIgcmVzcG9uc2UuDQo+IA0KPiAgICBZb3VyIGRvY3VtZW50IHdpbGwgbm90IG1vdmUg Zm9yd2FyZCB1bnRpbCB3ZSBoYXZlIHJlY2VpdmVkDQo+ICAgIGFwcHJvdmFscyBmcm9tIGVhY2gg b2YgdGhlIGF1dGhvcnMgbGlzdGVkIG9uIHRoZSBmcm9udCBwYWdlLg0KPiAgICBZb3VyIGFwcHJv dmFsIGluZGljYXRlcyB0aGF0IHlvdSBhcHByb3ZlIHRoZSAueG1sLCAuaHRtbCwgLnBkZiwNCj4g ICAgYW5kIC50eHQgZm9yIHB1YmxpY2F0aW9uLiBZb3VyIGFwcHJvdmFsIGFsc28gaW5kaWNhdGVz IHRoYXQgeW91IA0KPiBoYXZlDQo+ICAgIGVuZ2FnZWQgb3RoZXIgcGFydGllcyAoZS5nLiwgQ29u dHJpYnV0b3JzIG9yIFdvcmtpbmcgR3JvdXApIGFzDQo+ICAgIG5lY2Vzc2FyeSBiZWZvcmUgcHJv dmlkaW5nIHlvdXIgYXBwcm92YWwuDQo+IA0KPiAgICBJZiBzZW5kaW5nIGNoYW5nZXMsIHBsZWFz ZSBkbyBvbmUgb2YgdGhlIGZvbGxvd2luZzoNCj4gDQo+ICAgIGEuIFVwZGF0ZSB0aGUgcHJvdmlk ZWQgWE1MIGZpbGUsIHRoZW4gZW1haWwgdXMgdGhlIHJldmlzZWQgWE1MIA0KPiBmaWxlLg0KPiAg ICAgICBZb3UgbWF5IHVzZSBhbnkgZmlsZW5hbWUgZm9yIHRoZSByZXZpc2VkIGZpbGU7IHdlIHdp bGwgcmVuYW1lDQo+ICAgICAgIGl0IGFzIG5lZWRlZC4NCj4gDQo+ICAgLS1PUi0tDQo+IA0KPiAg ICBiLiBQcm92aWRlIHVzIHdpdGggYW4gZXhwbGljaXQgbGlzdCBvZiBjaGFuZ2VzIGluIHRoaXMg Zm9ybWF0Lg0KPiANCj4gICAgICAgU2VjdGlvbiAjIChvciBpbmRpY2F0ZSBHbG9iYWwpDQo+IA0K PiAgICAgICBPTEQ6DQo+ICAgICAgIG9sZCB0ZXh0DQo+IA0KPiAgICAgICBORVc6DQo+ICAgICAg IG5ldyB0ZXh0DQo+IA0KPiAgICBCZSBzdXJlIHRvIHBheSBwYXJ0aWN1bGFyIGF0dGVudGlvbiB0 byB0aGVzZSBhcmVhcyBvZiB0aGUNCj4gZG9jdW1lbnQ6DQo+ICAgIC0gSUFOQSBDb25zaWRlcmF0 aW9ucyB1cGRhdGVzIChpZiBhcHBsaWNhYmxlKQ0KPiAgICAtIENvbnRhY3QgaW5mb3JtYXRpb24N Cj4gICAgLSBDb3B5cmlnaHQgbm90aWNlIGFuZCBsZWdlbmRzOyBzZWUgdGhlIFRydXN0IExlZ2Fs IFByb3Zpc2lvbnMNCj4gKFRMUCkNCj4gICAgICAtLSBodHRwczovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvLw0KPiANCj4gICAgSW4gcGFydGljdWxhciBmb3IgWE1MdjMsIHBsZWFzZSBy ZXZpZXcgdGhlIFhNTCB0YWdnaW5nIHRvIGVuc3VyZSBpdA0KPiAgICBpcyBjb3JyZWN0LiBJbiBh ZGRpdGlvbiwgcGxlYXNlIGRvIHRoZSBmb2xsb3dpbmc6DQo+IA0KPiAgICBhKSBpZiBhcHBsaWNh YmxlLCByZXZpZXcgdGhlIHR5cGUgYXR0cmlidXRlIG9mIGVhY2ggc291cmNlY29kZSANCj4gZWxl bWVudA0KPiAgICAgICBpbiB0aGUgWE1MIGZpbGUgdG8gZW5zdXJlIGNvcnJlY3RuZXNzLiBTZWUg dGhlIHhtbDJyZmMgRkFRIGZvciANCj4gZGV0YWlscw0KPiAgICAgICAoaHR0cHM6Ly93d3cucmZj LWVkaXRvci5vcmcvbWF0ZXJpYWxzL0ZBUS0NCj4geG1sMnJmY3YzLmh0bWwjcV9zb3VyY2Vjb2Rl KS4NCj4gDQo+ICAgIGIpIHJldmlldyBlYWNoIGFydHdvcmsgZWxlbWVudC4gU3BlY2lmaWNhbGx5 LCBzaG91bGQgYW55IGFydHdvcmsgDQo+IGVsZW1lbnQNCj4gICAgICAgYmUgdGFnZ2VkIGFzIHNv dXJjZWNvZGUgb3IgYW5vdGhlciBlbGVtZW50Pw0KPiANCj4gICAgYykgdXBkYXRlIHRoZSBYTUwg aWYgeW91IHdvdWxkIGxpa2UgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgYW55IG9mIHRoZQ0KPiAgICAg ICBuZXcgZmVhdHVyZXMgYWxsb3dlZCBpbiBYTUwgdjMgKGUuZy4sIHN1cGVyc2NyaXB0IGFuZCBi b2xkKS4NCj4gDQo+IDQpIElmIHlvdXIgZG9jdW1lbnQgY29udGFpbnMgYW4gU1ZHIGltYWdlLCBw bGVhc2UgYmUgYXdhcmUgdGhhdCB0aGUNCj4gICAgUkZDIEVkaXRvciB3aWxsIGFzayB5b3UgdG8g bWFrZSBhbnkgbmVjZXNzYXJ5IGNoYW5nZXMgdG8gdGhhdCBmaWxlLg0KPiAgICBSZXZpc2lvbnMg dG8gU1ZHIGFyZSBtb3N0IGVhc2lseSBkb25lIGluIHRoZSB0b29sIHVzZWQgdG8gY3JlYXRlDQo+ ICAgIHRoZSBmaWxlLiAgUGxlYXNlIHVzZSBzdmdjaGVjayB0byB2YWxpZGF0ZSB5b3VyIFNWRyBm aWxlDQo+ICAgIGJlZm9yZSBzdWJtaXNzaW9uIChzZWUgaHR0cHM6Ly9weXBpLm9yZy9wcm9qZWN0 L3N2Z2NoZWNrLykuDQo+IA0KPiA1KSBSZXZpZXcgY2hhbmdlcyBzdWJtaXR0ZWQgYnkgeW91ciBj b2F1dGhvcnMgKGlmIGFueSkuICBXZSBhc3N1bWUgDQo+IHRoYXQNCj4gICAgeW91IHdpbGwgc3Bl YWsgdXAgaWYgeW91IGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBwcm9wb3NlZCBjaGFuZ2VzLg0KPiAg ICBUaGF0IGlzLCB5b3VyIHNpbGVuY2UgaXMgeW91ciBhc3NlbnQgdG8gY2hhbmdlcyBzdWJtaXR0 ZWQgYnkgeW91cg0KPiAgICBjb2F1dGhvcnMuIE5vdGUgdGhhdCBhbnkgY2hhbmdlcyB0aGF0IGFy ZSBiZXlvbmQgZWRpdG9yaWFsIHdpbGwgYmUNCj4gICAgc2VudCB0byB0aGUgcmVsZXZhbnQgYm9k eSBmb3IgYXBwcm92YWwuDQo+IA0KPiA2KSBQbGVhc2UgcmVwbHksIGFzIHRoZSBkb2N1bWVudCB3 aWxsIG5vdCBiZSBwdWJsaXNoZWQgdW50aWwgd2UgDQo+IHJlY2VpdmUNCj4gICAgYXBwcm92YWxz IGZyb20gZWFjaCBhdXRob3IuICBUaGUgZGV0YWlscyBvZiB0aGUgQVVUSDQ4IHN0YXR1cyBvZiAN Cj4geW91cg0KPiAgICBkb2N1bWVudCBhcmUgaGVyZToNCj4gDQo+ICAgIGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2F1dGg0OC9yZmM4OTA5DQo+IA0KPiBUaGFuayB5b3UgZm9yIHlvdXIgY29v cGVyYXRpb24sDQo+IA0KPiBSRkMgRWRpdG9yDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBSRkM4OTA5IChkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRl ci1jb250cm9sLTA3KQ0KPiANCj4gVGl0bGUgICAgICAgICAgICA6IENvbnRyb2xsaW5nIEZpbHRl cmluZyBSdWxlcyBVc2luZyBEaXN0cmlidXRlZA0KPiBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRo cmVhdCBTaWduYWxpbmcgKERPVFMpIFNpZ25hbCBDaGFubmVsDQo+IEF1dGhvcihzKSAgICAgICAg OiBLLiBOaXNoaXp1a2EsIE0uIEJvdWNhZGFpciwgVC4gUmVkZHksIFQuIE5hZ2F0YQ0KPiBXRyBD aGFpcihzKSAgICAgIDogTGlhbmcgWGlhLCBWYWxlcnkgU215c2xvdg0KPiBBcmVhIERpcmVjdG9y KHMpIDogUm9tYW4gRGFueWxpdywgQmVuamFtaW4gS2FkdWsNCj4gDQoNCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMK cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KCg== From nobody Mon Sep 14 02:19: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 2F96E3A0B23; Mon, 14 Sep 2020 02:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3ftSlCz9GOe; Mon, 14 Sep 2020 02:19:47 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A836E3A0B21; Mon, 14 Sep 2020 02:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=N6CNp9MvY9LXRp5QolwIo+WSd7rOT0M+hdU7XAuLI7s=; b=qMeLmRIkatopTBhXXp+cnO7FcY ydZt7FIeXM3W5G4bS3H6zwMI5xvINPUuhAFpIak+KFs2Kku2WHLCjeFVwofncDbK4wmDgziqfnsRj ElCkweIKv4KHMylZOrMLGij7azg6iVpWIie0+U34Ty74IqV7nSV2qU9lyE+YbcoC6TXeqamlZ+Xkb GBkJLKyJys8u4Y+Q/rV7Bye4XjGrCFD4fYgbm8OhywX6gFis1xGsdGy7BIwmu0+kkITbzRHhfgqdZ HDzzo1RwVt2jQ9z3soDcBFduMJ+mSD2dP4JNanDnQAMpMzJRUbpshngYrEN+CVfDaoN4Gu/jUyZnm Dh41QJBg==; Received: from [82.138.51.3] (port=57032 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kHkeG-0003IW-Cm; Mon, 14 Sep 2020 05:19:44 -0400 From: "Valery Smyslov" To: Cc: , "'H Y'" , References: <0be401d67c45$d4381080$7ca83180$@smyslov.net> In-Reply-To: <0be401d67c45$d4381080$7ca83180$@smyslov.net> Date: Mon, 14 Sep 2020 12:19:39 +0300 Message-ID: <047401d68a78$2e67c6f0$8b3754d0$@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: AQC/si2gBqg0NmaOTRo7QCYhoVLJSquVi4pg Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [Dots] Call for adoption of draft-hayashi-dots-telemetry-use-cases-00 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 09:19:48 -0000 Hi, taking into considerations the received feedback, the draft is adopted. Authors, please re-submit it as a WG document. Regards, Frank & Valery. > Hi, > > after discussion with Yuhei we decided to issue a call for adoption > of draft-hayashi-dots-telemetry-use-cases-00 as a WG document. > > Note, that the chairs have an opinion, that the DOTS WG has > already published quite a lot of informational documents, > describing DOTS requirements, architecture, use cases. > We think that having one more auxiliary document that > describes use cases only for an optional feature of DOTS > (telemetry) is not fully justified and it's probably better > to merge telemetry use cases draft with telemetry I-D. > We think that for implementers it's generally easier to look into > a single document, than to find a separate one > describing use cases. Another consideration is that > if a separate document is adopted, then the processing of > the telemetry I-D will probably have to be slow down until the telemetry use cases > draft is ready, so that they are sent to publication together > (in this case the telemetry draft will have a steady reference to RFC and > not to I-D). > > On the other hand, discussion on last DOTS meeting and > on the list indicated that quite a lot of people in the WG > prefer to have telemetry use cases as a separate > document, instead of merging it with the telemetry > draft. The concerns were expressed that telemetry > draft is already a long document and authors > don't want to make it longer. > > So, this message start a two weeks call for adoption of > draft-hayashi-dots-telemetry-use-cases-00 that will end 11 September. > Please, respond to the list with your preference among 2 options: > > 1. Adopt this draft as a separate document describing DOTS telemetry use cases. > 2. Don't adopt this draft and merge its content into the draft-ietf-dots-telemetry instead. > > We'll be very much appreciated if you also give reasoning for your choice. > > Regards, > Frank & Valery. From nobody Mon Sep 14 03:00:16 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 B37D53A00E0; Mon, 14 Sep 2020 03:00:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160007761469.3031.11836228229771485294@ietfa.amsl.com> Date: Mon, 14 Sep 2020 03:00:14 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-use-cases-00.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, 14 Sep 2020 10:00:15 -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 : Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry Authors : Yuhei Hayashi Meiling Chen Filename : draft-ietf-dots-telemetry-use-cases-00.txt Pages : 14 Date : 2020-09-14 Abstract: Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS- attack-mitigation techniques in a network. This document presents sample use cases for DOTS Telemetry: what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-use-cases-00 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-use-cases-00 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 Sep 14 03:21:33 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF53A03FB for ; Mon, 14 Sep 2020 03:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BIgyNw5RQzQ for ; Mon, 14 Sep 2020 03:21:29 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 50EFE3A03F1 for ; Mon, 14 Sep 2020 03:21:28 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea5f5f441d9ae-d346c; Mon, 14 Sep 2020 18:21:17 +0800 (CST) X-RM-TRANSID: 2eea5f5f441d9ae-d346c X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.53.240]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee55f5f441cfab-2a7d8; Mon, 14 Sep 2020 18:21:17 +0800 (CST) X-RM-TRANSID: 2ee55f5f441cfab-2a7d8 From: "SuLi" To: References: <160007761469.3031.11836228229771485294@ietfa.amsl.com> In-Reply-To: <160007761469.3031.11836228229771485294@ietfa.amsl.com> Date: Mon, 14 Sep 2020 18:21:15 +0800 Message-ID: <00e201d68a80$c745dda0$55d198e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdaKfdrG9wv53zGARgKIQQ2oQ2kb0gAAtg7Q Content-Language: zh-cn Archived-At: Subject: [Dots] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90?= =?gb2312?b?cy10ZWxlbWV0cnktdXNlLWNhc2VzLTAwLnR4dA==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 10:21:31 -0000 =D5=E2=B8=F6=B0=C9=A3=AC=D3=D6=CA=C7=B9=A4=D7=F7=D7=E9=CE=C4=B8=E5=C1=CB~= =C8=E7=B9=FB=D3=D0=BF=D5=CE=BB=D6=C3=A3=AC=BE=CD=B0=D1=CE=D2=BC=D3=C9=CF=C8= =A5=B2=E4=C9=CF=A1=A3 Best Regards! Su Li(=CB=DA=C0=F5) -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Dots [mailto:dots-bounces@ietf.org] =B4=FA=B1=ED = internet-drafts@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA9=D4=C214=C8=D5 18:00 =CA=D5=BC=FE=C8=CB: i-d-announce@ietf.org =B3=AD=CB=CD: dots@ietf.org =D6=F7=CC=E2: [Dots] I-D Action: = draft-ietf-dots-telemetry-use-cases-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the = IETF. Title : Use Cases for DDoS Open Threat Signaling = (DOTS) Telemetry Authors : Yuhei Hayashi Meiling Chen Filename : draft-ietf-dots-telemetry-use-cases-00.txt Pages : 14 Date : 2020-09-14 Abstract: Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS- attack-mitigation techniques in a network. This document presents sample use cases for DOTS Telemetry: what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-use-cases-00 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-use-cases= -00 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Sep 14 03:24:04 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538273A053E for ; Mon, 14 Sep 2020 03:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HENPGpXHJnzv for ; Mon, 14 Sep 2020 03:24:02 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53A93A0489 for ; Mon, 14 Sep 2020 03:24:01 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id x19so17314142oix.3 for ; Mon, 14 Sep 2020 03:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=1saRNz+Vh0bxM4iWu5caUuzkaQF9I1xjQv0EekC2D4s=; b=jeVmMbcmCPPUsrqF25iEQ7D77gD3IqZXLNjxIJvrEUGAy4SlndKoY4Zy1WsAOdsEQ9 cMEwZOpZZ92d6Q0jifkuWCxcbvStPjqTDh28ikvtjI2VMoC4OOJxPSbMlbctI1H5Wqoi wqT/vtZJIR7ZVDrZQfjgzhgDqnWtPtQc+L37DOrycxdh0C3puQuv1s7g2O0Ke0gTTuu+ 0ccU9+5TyqyEX5DVxb9yFZRgVc8eQNIYb4CgBA+Yin+Ga62xP1qrNf5TXiL3Aes9v3y5 WXSNoIpxQyMQJjzCShqGtI2lJcBmGxF+FdquOcIg65eihz04z6qyVR/MY1mkTHeUgsTl PIrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=1saRNz+Vh0bxM4iWu5caUuzkaQF9I1xjQv0EekC2D4s=; b=G8xxZdgiGFC6eWC8EjLiW7triMHLI+Ox6uKVJ0Rm9jpXeyNoKqbRmantqlye3WVDNH mv6VLF6Xfv6WOWH50d9Y3n+pEmJDTwzpLmNiU+h0XGtxTQINPWuYzikvASNkD7ACvzwR A1cUVJqeVksOjf19CEVjCDVjCCU8mZSYK8PbTCR+q04evU4yr9WJ5StlKDoi0Fb5rZan qerMWT3KK1S0drIuNpPOoXwA6Q50w/J32ffrw1FZSvCpbKoTI85f2ca6Vxwba9PSh3WS +KSaTuKzcs8ZyN1XyK3O/NjR3ilHL/g5I3Qmw/KDNXTafZ9kGogDn0EeKXXKJ/Ps5XWO 5ahQ== X-Gm-Message-State: AOAM530E35EbcYCK5YuWYeNaaRA5RCHsJXEVXp88tnqq2Z78+dqgCNp0 /ZdCQZPCTJsU17GEghcLm9drBp41MWze3gkjaM4OEfd/ X-Google-Smtp-Source: ABdhPJwjaIejI6M8kC3SsnVXlqfaaanENvH9FpQNGiKUXZ3+zmaljewkto+f9aGKwGlKUQi8oL3idoDy6IG8PQORMt4= X-Received: by 2002:aca:de08:: with SMTP id v8mr8004945oig.82.1600079040829; Mon, 14 Sep 2020 03:24:00 -0700 (PDT) MIME-Version: 1.0 References: <160007761489.3031.2296950981503653919@ietfa.amsl.com> In-Reply-To: <160007761489.3031.2296950981503653919@ietfa.amsl.com> From: H Y Date: Mon, 14 Sep 2020 19:23:48 +0900 Message-ID: To: dots Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-telemetry-use-cases-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 10:24:03 -0000 Hi all, Thank you for supporting the draft. I will improve the draft as below. >- Adding additional use cases > Usage of baseline and total-attack-connections and so on. > Signaling from server to client https://www.ietf.org/proceedings/interim-2020-dots-01/slides/slides-interim= -2020-dots-01-sessa-dots-telemetry-use-cases-00.pdf Comments and co-authors are welcome. Thanks, Yuhei 2020=E5=B9=B49=E6=9C=8814=E6=97=A5(=E6=9C=88) 19:00 : > > > A new version of I-D, draft-ietf-dots-telemetry-use-cases-00.txt > has been successfully submitted by Yuhei Hayashi and posted to the > IETF repository. > > Name: draft-ietf-dots-telemetry-use-cases > Revision: 00 > Title: Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry > Document date: 2020-09-14 > Group: dots > Pages: 14 > URL: https://www.ietf.org/id/draft-ietf-dots-telemetry-use-cas= es-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetr= y-use-cases/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dots-tel= emetry-use-cases > Htmlized: https://tools.ietf.org/html/draft-ietf-dots-telemetry-use= -cases-00 > > > Abstract: > Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the > base DOTS protocols to assist the mitigator in using efficient DDoS- > attack-mitigation techniques in a network. This document presents > sample use cases for DOTS Telemetry: what components are deployed in > the network, how they cooperate, and what information is exchanged to > effectively use these techniques. > > > > > 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. > > The IETF Secretariat > > -- ---------------------------------- Yuuhei HAYASHI 08065300884 yuuhei.hayashi@gmail.com iehuuy_0220@docomo.ne.jp ---------------------------------- From nobody Mon Sep 14 03:51:43 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775A93A081F for ; Mon, 14 Sep 2020 03:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.499 X-Spam-Level: * X-Spam-Status: No, score=1.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6oRxLZ4xhSs for ; Mon, 14 Sep 2020 03:51:40 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 315063A0816 for ; Mon, 14 Sep 2020 03:51:38 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee25f5f4b2df79-d1e90; Mon, 14 Sep 2020 18:51:25 +0800 (CST) X-RM-TRANSID: 2ee25f5f4b2df79-d1e90 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[117.136.0.173]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee15f5f4b2cae6-d1d39; Mon, 14 Sep 2020 18:51:25 +0800 (CST) X-RM-TRANSID: 2ee15f5f4b2cae6-d1d39 From: "SuLi" To: Date: Mon, 14 Sep 2020 18:51:22 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01D68AC8.0B44F850" X-Mailer: Microsoft Office Outlook 12.0 Expiry-Date: Wed, 16 Sep 2020 18:51:20 +0800 X-MS-TNEF-Correlator: 00000000E339C3EAE1148F45BCC35784E079398D4481B500 Archived-At: Subject: [Dots] =?gb2312?b?s7e72DogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90?= =?gb2312?b?cy10ZWxlbWV0cnktdXNlLWNhc2VzLTAwLnR4dA==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 10:51:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01D68AC8.0B44F850 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VMaSC9q7O3u9jTyrz+obBbRG90c10gSS1EIEFjdGlvbjoNCmRyYWZ0LWlldGYtZG90cy10ZWxl bWV0cnktdXNlLWNhc2VzLTAwLnR4dKGxoaMNCg== ------=_NextPart_000_0006_01D68AC8.0B44F850 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhgKAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAqAMAAAAAAACrAAEIgAcAEwAAAElQTS5PdXRs b29rLlJlY2FsbACCBgEDkAYAFAQAABgAAAADACYAAQAAAAIBMQABAAAADQEAAFBDREZFQjA5AAEA AgBkAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4A AAAARAA6AFwAbwB1AHQAbABvAG8AawBcAE8AdQB0AGwAbwBvAGsALgBwAHMAdAAAABgAAAAAAAAA 4znD6uEUj0W8w1eE4Hk5jcKAAAAYAAAAAAAAAOM5w+rhFI9FvMNXhOB5OY3kf7UAAAAAABAAAADz PvO4ncnQRrf5ua6w7EPCRAAAALTwuLQ6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRv dHMtdGVsZW1ldHJ5LXVzZS1jYXNlcy0wMC50eHQAAAAACwABDgEAAAADABQOAQAAAAIBAGgBAAAA EAAAAPM+87idydBGt/m5rrDsQ8IDAAFoAQAAAB4AAmgBAAAACQAAAElQTS5Ob3RlAAAAAAsAA2gB AAAAAwAEaAAAAAADADOACCAGAAAAAADAAAAAAAAARgAAAAAahQAAAQAAAAsAHw4BAAAAAgH4DwEA AAAQAAAA4znD6uEUj0W8w1eE4Hk5jQIB+g8BAAAAEAAAAOM5w+rhFI9FvMNXhOB5OY0DAP4PBQAA AAIBCRABAAAANwEAADMBAADuAQAATFpGdTgk1kgDAAoAcmNwZzEyNSIyA0N0ZXgFQmJp/mQEAAMw AQMB9wqAAqQD4wkCAGNoCsBzZXQw/iAHEwKAEHMAUARWCFUHsu8SRQ5RAwERRzIGAAbDEkVOMwRG EUkTX2Y0EN4xjDM0BgAHcHN1bgKAtxJTCO8J9zsbXw4wNRJCnQxgYwBQCwkBZDM2EdDDC6YDMGh0 bWwAIRiFhwwBIEUR0FN1TGkDMPQnYgswJwyhIkAWUCJAZjciMSKhZDgjcSLhY8ZhIjEA4CdmZSJx AFABIkAwW0RvdHNdECBJLUQR4GN0aUECIDogZHJhAYAtUwiQADAtZCVRLQ6wbIJlB4B0cnktdRGg ji0kEBGgJ0AwMC4M0O50JLUk4STSYRZQIEUCsS59IUgKogqAfSvQAAMADTT9P6UGAwAPNP0/pQYC ARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBFMzM5QzNFQUUx MTQ4RjQ1QkNDMzU3ODRFMDc5Mzk4RDQ0ODFCNTAwAAAAAAMABhAWo1G5AwAHEEsAAAADABAQAAAA AAMAERAAAAAAHgAIEAEAAABMAAAAU1VMSb2rs7e72NPKvP6hsERPVFNJLURBQ1RJT046RFJBRlQt SUVURi1ET1RTLVRFTEVNRVRSWS1VU0UtQ0FTRVMtMDBUWFShsaGjALYK ------=_NextPart_000_0006_01D68AC8.0B44F850-- From nobody Mon Sep 14 03:52:01 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C843A0813 for ; Mon, 14 Sep 2020 03:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc_2Hwp5uR87 for ; Mon, 14 Sep 2020 03:51:58 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id E47CE3A0816 for ; Mon, 14 Sep 2020 03:51:57 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea5f5f4b42217-d3cd5; Mon, 14 Sep 2020 18:51:46 +0800 (CST) X-RM-TRANSID: 2eea5f5f4b42217-d3cd5 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[117.136.0.173]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee55f5f4b41f22-d9654; Mon, 14 Sep 2020 18:51:46 +0800 (CST) X-RM-TRANSID: 2ee55f5f4b41f22-d9654 From: "SuLi" To: Date: Mon, 14 Sep 2020 18:51:43 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01D68AC8.17E4A100" X-Mailer: Microsoft Office Outlook 12.0 Expiry-Date: Wed, 16 Sep 2020 18:51:42 +0800 X-MS-TNEF-Correlator: 00000000E339C3EAE1148F45BCC35784E079398D6481B500 Archived-At: Subject: [Dots] =?gb2312?b?s7e72DogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90?= =?gb2312?b?cy10ZWxlbWV0cnktdXNlLWNhc2VzLTAwLnR4dA==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 10:52:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01D68AC8.17E4A100 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VMaSC9q7O3u9jTyrz+obBbRG90c10gSS1EIEFjdGlvbjoNCmRyYWZ0LWlldGYtZG90cy10ZWxl bWV0cnktdXNlLWNhc2VzLTAwLnR4dKGxoaMNCg== ------=_NextPart_000_0009_01D68AC8.17E4A100 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+Ii0KAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAqAMAAAAAAACrAAEIgAcAEwAAAElQTS5PdXRs b29rLlJlY2FsbACCBgEDkAYAFAQAABgAAAADACYAAQAAAAIBMQABAAAADQEAAFBDREZFQjA5AAEA AgBkAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4A AAAARAA6AFwAbwB1AHQAbABvAG8AawBcAE8AdQB0AGwAbwBvAGsALgBwAHMAdAAAABgAAAAAAAAA 4znD6uEUj0W8w1eE4Hk5jcKAAAAYAAAAAAAAAOM5w+rhFI9FvMNXhOB5OY3kf7UAAAAAABAAAADz PvO4ncnQRrf5ua6w7EPCRAAAALTwuLQ6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRv dHMtdGVsZW1ldHJ5LXVzZS1jYXNlcy0wMC50eHQAAAAACwABDgEAAAADABQOAQAAAAIBAGgBAAAA EAAAAPM+87idydBGt/m5rrDsQ8IDAAFoAQAAAB4AAmgBAAAACQAAAElQTS5Ob3RlAAAAAAsAA2gB AAAAAwAEaAAAAAADADOACCAGAAAAAADAAAAAAAAARgAAAAAahQAAAQAAAAsAHw4BAAAAAgH4DwEA AAAQAAAA4znD6uEUj0W8w1eE4Hk5jQIB+g8BAAAAEAAAAOM5w+rhFI9FvMNXhOB5OY0DAP4PBQAA AAIBCRABAAAANwEAADMBAADuAQAATFpGdTgk1kgDAAoAcmNwZzEyNSIyA0N0ZXgFQmJp/mQEAAMw AQMB9wqAAqQD4wkCAGNoCsBzZXQw/iAHEwKAEHMAUARWCFUHsu8SRQ5RAwERRzIGAAbDEkVOMwRG EUkTX2Y0EN4xjDM0BgAHcHN1bgKAtxJTCO8J9zsbXw4wNRJCnQxgYwBQCwkBZDM2EdDDC6YDMGh0 bWwAIRiFhwwBIEUR0FN1TGkDMPQnYgswJwyhIkAWUCJAZjciMSKhZDgjcSLhY8ZhIjEA4CdmZSJx AFABIkAwW0RvdHNdECBJLUQR4GN0aUECIDogZHJhAYAtUwiQADAtZCVRLQ6wbIJlB4B0cnktdRGg ji0kEBGgJ0AwMC4M0O50JLUk4STSYRZQIEUCsS59IUgKogqAfSvQAAMADTT9P6UGAwAPNP0/pQYC ARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBFMzM5QzNFQUUx MTQ4RjQ1QkNDMzU3ODRFMDc5Mzk4RDY0ODFCNTAwAAAAAAMABhAWo1G5AwAHEEsAAAADABAQAAAA AAMAERAAAAAAHgAIEAEAAABMAAAAU1VMSb2rs7e72NPKvP6hsERPVFNJLURBQ1RJT046RFJBRlQt SUVURi1ET1RTLVRFTEVNRVRSWS1VU0UtQ0FTRVMtMDBUWFShsaGjALgK ------=_NextPart_000_0009_01D68AC8.17E4A100-- From nobody Mon Sep 14 23:01:01 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E23863A0E8F; Mon, 14 Sep 2020 23:00:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160014965486.4877.18032043993093344590@ietfa.amsl.com> Date: Mon, 14 Sep 2020 23:00:54 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-call-home-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: Tue, 15 Sep 2020 06:00: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) Signal Channel Call Home Authors : Tirumaleswar Reddy Mohamed Boucadair Jon Shallow Filename : draft-ietf-dots-signal-call-home-09.txt Pages : 37 Date : 2020-09-14 Abstract: This document specifies the DOTS signal channel Call Home, which enables a DOTS server to initiate a secure connection to a DOTS client, and to receive the attack traffic information from the DOTS client. The DOTS server in turn uses the attack traffic information to identify the compromised devices launching the outgoing DDoS attack and takes appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to the home networks; the solution targets any deployment which requires to block DDoS attack traffic closer to the source(s) of a DDoS attack. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- rfc8782-bis) Please update TBD statements with the assignment made by IANA to DOTS Signal Channel Call Home. Also, please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-09 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call-home-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-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 Mon Sep 14 23:05: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 988D73A0EAC for ; Mon, 14 Sep 2020 23:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 t5UGnn1u9Cic for ; Mon, 14 Sep 2020 23:05:09 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886373A0EA9 for ; Mon, 14 Sep 2020 23:05:09 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4BrCPb6M6WzCrk8; Tue, 15 Sep 2020 08:05:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1600149907; bh=w8teIm+iRKfPdZnPwz7lXObRUsFEM2GvIcqKyp7mOnA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=uZZKjzY+u3QmtnPsBmH6Ogr1RmNLrGPpwygBiDc/lVK/v0fXexa+mDz2sOiDM5T56 8jmkSjZgVq4Kiprn4D5Rnhworj3OeWlhhD12OZA0ag7O2+GfXu6spo9eJt28iYF2BA 8fQnkY6DRiiEr8jXiR0phr7EJ7IB6bcnFgaPXLDaiEZkwsyuVKqWiB1NGvfyPSkqlN 3nNk5CuWNNN2yDICqOXld+WR0l3F5qrsZ6DGWze72MVM1NgSNOEWorLu0HIu+IkPmS Le1cTLwfX7JrmGMaFtb8XlcglDFs6q3v+eMlZGZ0CexjLQfYlu0Xr1H2v+JkOt7Vgg gMN4rEYILLa4Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4BrCPb5Vmrz1xpF; Tue, 15 Sep 2020 08:05:07 +0200 (CEST) From: To: "dots@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: I-D Action: draft-ietf-dots-signal-call-home-09.txt Thread-Index: AQHWiyWfM4vObSwKRUSLdMrRmTMiLKlpNXvQ Date: Tue, 15 Sep 2020 06:05:07 +0000 Message-ID: <28148_1600149907_5F605993_28148_13_1_787AE7BB302AE849A7480A190F8B933031540A47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160014965486.4877.18032043993093344590@ietfa.amsl.com> In-Reply-To: <160014965486.4877.18032043993093344590@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-signal-call-home-09.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, 15 Sep 2020 06:05:12 -0000 Hi Ben, all,=20 The main update is to refer to 8782bis instead of 8782 and tweak the yang m= odule accordingly.=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 15 septembre 2020 08:01 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-signal-call-home-09.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) Signal Channel Call Home > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Jon Shallow > Filename : draft-ietf-dots-signal-call-home-09.txt > Pages : 37 > Date : 2020-09-14 >=20 > Abstract: > This document specifies the DOTS signal channel Call Home, which > enables a DOTS server to initiate a secure connection to a DOTS > client, and to receive the attack traffic information from the > DOTS > client. The DOTS server in turn uses the attack traffic > information > to identify the compromised devices launching the outgoing DDoS > attack and takes appropriate mitigation action(s). >=20 > The DOTS signal channel Call Home is not specific to the home > networks; the solution targets any deployment which requires to > block > DDoS attack traffic closer to the source(s) of a DDoS attack. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements within the document with the RFC > number to be assigned to this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Call Home"; >=20 > o "| [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > Please update this statement with the RFC number to be assigned > to > the following documents: >=20 > o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification" (used to be I-D.ietf- > dots- > rfc8782-bis) >=20 > Please update TBD statements with the assignment made by IANA to > DOTS > Signal Channel Call Home. >=20 > Also, please update the "revision" date of the YANG module. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call- > home-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-call-home- > 09 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Sep 18 13:22:23 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0789B3A0AE6; Fri, 18 Sep 2020 13:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ceYio5Htk9Tl; Fri, 18 Sep 2020 13:22:20 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B423A0921; Fri, 18 Sep 2020 13:22:16 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08IKMC51021501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Sep 2020 16:22:14 -0400 Date: Fri, 18 Sep 2020 13:22:11 -0700 From: Benjamin Kaduk To: draft-ietf-dots-server-discovery.all@ietf.org Cc: dots@ietf.org Message-ID: <20200918202211.GI89563@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Dots] AD review of draft-ietf-dots-server-discovery-10 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, 18 Sep 2020 20:22:22 -0000 Hi all, Despite the first half of the review basically being entirely nits, there are some substantive comments in there later on. (Would it be helpful if I tried harder to split the nits out into a separate section in the future?) Overall it's pretty straightforward, so no major issues left to address; sorry for taking so long to get through it. One thing that we should definitely fix before getting more eyes on this document is that both TBD1 and TBD2 are overloaded -- we use them to refer to the port assignments from the signal channel and call home protocol assignments, but also for the DHCPv6 option codes. Abstract The first paragraph seems to be generic about all of DOTS, not really very specific to discovery. I wonder if we want to just remove the first paragraph or perhaps swap the order, the latter of which might look like: % This document specifies mechanisms to configure Districuted Denial of % Service Open Threat Signaling (DOTS) clients with their DOTS servers. % The discovery procedure also covers the DOTS Signal Channel Call Home. % % Knowing the appropriate DOTS server for a given location can be useful % to engage mitigation actions even in cases where the DOTS client % cannot localize the attack, but only knows that some resources are % under attack and that help is needed. Section 1 appropriate mitigation actions are required. Indeed, because the lack of a common method to coordinate a real-time response among involved actors and network domains inhibits the effectiveness of DDoS attack mitigation, DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is meant to carry requests for DDoS nit: missing "the" before "DOTS signal channel protocol". attack mitigation, thereby reducing the impact of an attack and leading to more efficient defensive actions in various deployment scenarios such as those discussed in [I-D.ietf-dots-use-cases]. nit: (also, this sentence is fairly long, though not necessarily problematic.) Moreover, DOTS clients can instruct a DOTS server to install filtering rules by means of the DOTS data channel protocol [I-D.ietf-dots-data-channel]. nit: maybe "named filtering rules", since that is an important aspect of how we interact with them. [I-D.ietf-dots-architecture] specifies that the DOTS client may be provided with a list of DOTS servers; each associated with one or nit: comma here, rather than semicolon. This document assumes that security credentials to authenticate DOTS server(s) are provisioned to a DOTS client using a variety of means such as (but not limited to) those discussed in [RFC8572] or nit: "using a variety of means" implies that all are used concurrently; do we really mean "any of" or "one of"? Section 2 The reader should be familiar with the terms defined in [I-D.ietf-dots-architecture], [RFC3958], and [I-D.ietf-dots-signal-call-home]. A bit surprising to not see RFCx 8782/8783 in there, too :) Section 3 o Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a CPE device. Multiple CPEs, connected to distinct network nit(?): I think "Many of the use cases" reads better. providers may even be considered. It is intuitive to leverage on nits: comma after "providers"; s/on$// o Resolving a DOTS server domain name offered by an upstream transit provider provisioned to a DOTS client into IP address(es) require nit: s/require/requires/ o Some of the use cases may allow DOTS clients to have direct communications with upstream DOTS servers; that is no DOTS gateway nit: comma/semicolon usage; let's go for "DOTS servers, that is, no DOTS gateway" is involved. Leveraging on existing features that do not require nit: s/Leveraging on/Leveraging/ specific feature on the node embedding the DOTS client may ease nit: we use "features" and "feature" in this sentence, which makes it a little hard to understand what's going on. Are the initial "features" more of "protocol behaviors"? Section 4 A key point in the deployment of DOTS is the ability of network operators to be able to configure DOTS clients with the correct DOTS nit: "ability" and "to be able to" are redundant (I suggest s/to be able to/to/) All DOTS clients MUST support at least one of the three mechanisms below to determine a DOTS server list. All DOTS clients SHOULD implement all three, or as many as are practical for any specific device (e.g., a CPE will support the first two mechanisms, a host within a LAN will support the last two mechanisms, or an application server will support a local configuration. More samples are discussed in Section 3), of these ways to discover DOTS servers, in order to facilitate the deployment of DOTS in large scale environments: nit: the way the parenthetical is structured is a bit unusual, with a sentence break occurring within the parentheses (and leaving quite a gap for processing in the middle of the thought "implement all three of these ways"). It's probably okay to just make the "SHOULD implement all three" a single standalone sentence, and leave the clarification of when implementing all three is infeasible/unnecessary to a follow-up sentence. server. When only DOTS server's IP addresses are configured, a reference identifier must also be configured for authentication purposes. Forestalling my common questions; good work! * Automatic configuration (e.g., DHCP, an automation system): The DOTS client attempts to discover DOTS server(s) names and/ or addresses from DHCP, as described in Section 5. We may get questions about this one, since it is apparently equating DHCP with a (generic) "automation system". Perhaps we want to say that the DHCP mechanism is used in the absence of manual or automated explicit configuration? the relevant DOTS server is obtained directly. Implementation options may vary on a per device basis, as some devices may not have DNS capabilities and/or proper configuration. nit: maybe "proper DNS configuration" or "proper resolver configuration"? combination of interface and address family. A DOTS client may choose to perform the discovery procedure only for a desired interface/address combination if the client does not wish to discover nit: I think "interface/address-family combination". o Expiry of a lease associated with a discovered DOTS agent. Is this specifically a DHCP lease, or a more generic concept? Section 5 As reported in Section 1.7.2 of [RFC6125]: "few certification authorities issue server certificates based on IP addresses, but preliminary evidence indicates that such I think the quote is actually "[s]ome", not "few" -- please check! The list of the IP addresses returned by DHCP servers is typically used to fed the DOTS server selection procedure or to provide DOTS nit: s/fed/feed/ for the DOTS Call Home. The DOTS client (or Call Home DOTS server) will then use the address selection specified in Section 4.3 of nit: "address selection procedure" Let's consider that the DOTS server is reachable at 2001:db8:122:300::1 while the Call Home DOTS client is reachable at 2001:db8:122:300::2. The DHCP server will then return one DOTS reference identifier and a list that includes both 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP client. That list is passed to the DOTS client (or Call Home DOTS server) which will try to establish connections to the addresses of that list and destination port number TBD1 (or TBD2). As a result, the DOTS client (or Call Home DOTS server) will select 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or Call Home DOTS client). I mostly expect pushback from TSV-area reviewers about giving the allocated port numbers such importance in selecting the peer address to use. Section 5.1.2 format of this option is shown in Figure 5. As a reminder, this format follows the guidelines for creating new DHCPv6 options (Section 5.1 of [RFC7227]). We need the reminder for the second option but not the first one? ;) Section 5.1.3 are used to reach the peer DOTS agent. In other words, the name conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a response. I'm not sure how much of this needs to end up in the document itself, but can we walk through the scenarios here, especially when the DNS-resolution addresses for the name in question differ from the addresses in OPTION_V6_DOTS_ADDRESS? I don't understand yet why/how this scheme ends up being safe, and am hoping that you have a head start over me on doing the analysis :) If the DHCP client receives OPTION_V6_DOTS_RI only, but OPTION_V6_DOTS_RI option contains more than one name, as nit: insert "the" at the start of the second line. If the DHCP client receives OPTION_V6_DOTS_RI only, but OPTION_V6_DOTS_RI option contains more than one name, as distinguished by the presence of multiple root labels, the DHCP client MUST use only the first name. Once the name is validated Is there a reason to make this "use the first one" vs. "ignore the whole thing as malformed? (Section 8 of [RFC8415]), the name is passed to a name resolution library. Moreover, that name is also used as a reference identifier for authentication purposes. Hmm, I'm not seeing much in Section 8 specifically of RFC 8415 that looks relevant here. Was perhaps a different document intended? Section 5.2.1 A reference to 2132 here would be timely, not least for understanding the figure. The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding. super-nitty-nit: maybe "the octets of the domain name labels"? IIUC the RFC 2132 convention is to give such names to the individual bytes of the DHCP option, but this wording implies that we are naming labels, which are multi-byte (except for the root). Section 5.2.2 I wonder if anyone will complain that we are using a more "modern" structure for the figure, instead of keeping with the "traditional" DHCP option diagrams. Section 5.2.3 To discover a peer DOTS agent, the DHCPv4 client MUST include both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request List Option [RFC2132]. Why is the v4 case a MUST but the v6 case was only MAY? If the DHCP client receives more than one instance of OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use only the first instance of that option. I think the parenthetical needs to be dropped, since in the previous section we say that this is a concatenation-requiring option. If the DHCP client receives OPTION_V4_DOTS_RI only, but OPTION_V4_DOTS_RI option contains more than one name, as distinguished by the presence of multiple root labels, the DHCP client MUST use only the first name. Once the name is validated (Section 10 of [RFC8415]), the name is passed to a name resolution library. Moreover, that name is also used as a reference identifier for authentication purposes. [same comments about "use first" as for v4] I see that here we reference §10, rather than 8, of RFC 8415, though it still doesn't say much explicitly about a "validation procedure". The diff between §5.1.3 and 5.2.3 includes "(e.g., PKIX [RFRC6125])" only in 5.1.3; it seems like it would also apply here. The DHCP client MUST silently discard multicast and host loopback addresses conveyed in OPTION_V4_DOTS_ADDRESS. Can we put a reference for "multicast and host loopback" addresses as we did for the v6 case? Section 6 1. A DNS domain name is retrieved for each combination of interface and address family. A DOTS agent has to determine the domain in which it is located relying on dynamic means such as DHCP (Section 5) . [...] Hmm, this may be worth a closer look. If I understand correctly, if the procedures in Section 5 only give you a name, you're supposed to use DNS to get IP addresses to talk to, from that name. So is this procedure only applicable when the A/AAAA lookup fails? Otherwise I'm not sure how you would get only a name but not full contact information, from the section 5 procedure. Or, if the intent of "the name is passed to a name resolution library" in Section 5 is to induce the S-NAPTR lookups defined here, Section 5 should be more clear about that. Once the DOTS agent has retrieved its DNS domain or discovered the peer DOTS agent name that needs to be resolved (e.g., Section 5), an (The parenthetical seems redundant with step (1).) S-NAPTR lookup with 'DOTS' application service and the desired [...] This specification defines "DOTS" and "DOTS-CALL-HOME" as application service tags (Sections 9.4.1 and 9.4.2). It also defines We should probably mention "DOTS-CALL-HOME" in both places, or just say something generic like "the appropriate application service" in the first instance, instead of only saying 'DOTS' the first time. a.example.net. IN AAAA 2001:db8::1 I'm sure my INT-area colleagues will appreciate the IPv6 examples :) Section 8 Having a clearly defined priority order for using the different discovery mechanisms covers most of the potential security considerations inherently, but I think some text is in order about whether an attacker can block/modify traffic to force a "lower priority" mechanism to be used (but would not be able to modify the "higher priority" mechanism's results with the same capabilities). We may also want to reiterate that discovery results are scoped by interface and address family, and that bad things can happen if you use a result from one interface for traffic from a different interface. There are probably not particularly interesting privacy considerations of advertising/exposing DOTS server names in these various discovery mechanisms, but a brief section on privacy considerations is likely in order regardless. Section 8.2 The primary attack against the methods described in Section 6 is one that would lead to impersonation of a peer DOTS agent. An attacker could attempt to compromise the S-NAPTR resolution. The use of mutual authentication makes it difficult to redirect a DOTS client (or a Call Home DOTS server) to an illegitimate DOTS server (or a Call Home DOTS client). IIUC this property only holds if the domain name used for authenticating the peer (i.e., the input to the RFC 6125 procedures) is the one used as input to the procedure in Section 6, not the intermediate names produced during that procedure (e.g., "example.net" as input and "a.example.net" as intermediate, from Figure 10). I don't think we specify anywhere that this must be the case, so on the face of it it seems that in the absence of DNSSEC, an attacker spoofing DNS responses can redirect the client to an arbitrary name controlled by the attacker, for which the attacker has valid PKIX credentials. (We also allow SRV-IDs for validation, so the SRV names are also affected.) I also note that the analogous question for mail servers (whether they authenticate as example.net or a.example.net) is a recurring source of trouble, so our hand may be forced by deployment realities. Section 8.3 I was going to say that we should reference the RFC 6763 security considerations, too, but they are just saying the same things we already say. Section 12.2 I expect at least one AD to suggest that the architecture draft should be normative since we require it for terminology, but I don't insist on changing its classification at this time. (Likewise for Call Home.) -Ben From nobody Mon Sep 21 03:38:12 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C13A0C11; Mon, 21 Sep 2020 03:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87k2RimxHxj2; Mon, 21 Sep 2020 03:38:07 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E19C3A0C22; Mon, 21 Sep 2020 03:38:06 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kKJCu-0004mH-U8; Mon, 21 Sep 2020 11:38:05 +0100 From: "Jon Shallow" To: "'Benjamin Kaduk'" , , References: <20200918202211.GI89563@kduck.mit.edu> In-Reply-To: <20200918202211.GI89563@kduck.mit.edu> Date: Mon, 21 Sep 2020 11:37:50 +0100 Message-ID: <0e5c01d69003$4136cb60$c3a46220$@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: AQEwuvmxS5Xz4YtXSK1AB6iIOXPPE6q+jhrA Content-Language: en-gb Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-server-discovery-10 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 10:38:11 -0000 Hi Ben, [I did send this out previously but provided a bad email address - sorry] > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Benjamin Kaduk > Sent: 18 September 2020 21:22 > To: draft-ietf-dots-server-discovery.all@ietf.org > Cc: dots@ietf.org > Subject: [Dots] AD review of draft-ietf-dots-server-discovery-10 Thanks for this, I have implemented this (for both DOTS client r and Call Home DOTS server) as IP-Address Domain DHCP S-NAPTR DNS-SD And one or more of these can be defined, so providing a search order. I will try to address the more technical comments that you raised as some of these may have been triggered by doing the above work. For the sake of brevity, I am skipping over the nits which can be addressed by the authors. > > o Expiry of a lease associated with a discovered DOTS agent. > > Is this specifically a DHCP lease, or a more generic concept? Interesting question - DNS has a TTL - should we be enforcing a refresh here as well? - my implementation does not do this at present > Let's consider that the DOTS server is reachable at > 2001:db8:122:300::1 while the Call Home DOTS client is reachable > at 2001:db8:122:300::2. The DHCP server will then return one DOTS > reference identifier and a list that includes both > 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP > client. That list is passed to the DOTS client (or Call Home DOTS > server) which will try to establish connections to the addresses > of that list and destination port number TBD1 (or TBD2). As a > result, the DOTS client (or Call Home DOTS server) will select > 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or > Call Home DOTS client). > > I mostly expect pushback from TSV-area reviewers about giving the > allocated port numbers such importance in selecting the peer address > to use. We do need a method for differentiation between whether the address is for a DOTS server or Call Home Dots client. > Section 5.1.3 > > are used to reach the peer DOTS agent. In other words, the name > conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying > resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a > response. > > I'm not sure how much of this needs to end up in the document itself, > but can we walk through the scenarios here, especially when the > DNS-resolution addresses for the name in question differ from the > addresses in OPTION_V6_DOTS_ADDRESS? I don't understand yet why/how > this scheme ends up being safe, and am hoping that you have a head > start over me on doing the analysis :) I don't immediately recall the rational for this, but if both are returned there needs to be a preference for one of them and think that OPTION_V6_DOTS_ADDRESS is the priority. It is conceivable that the OPTION_V6_DOTS_RI, when resolved, may point to an address that is not in the local domain (i.e. traffic needs to go via a DOTS gateway rather than direct to a DOTS server). > If the DHCP client receives OPTION_V6_DOTS_RI only, but > OPTION_V6_DOTS_RI option contains more than one name, as > distinguished by the presence of multiple root labels, the DHCP > client MUST use only the first name. Once the name is validated > > Is there a reason to make this "use the first one" vs. "ignore the > whole thing as malformed? 5.1.1. implies that that there can only be a singular dots-agent-name, so I would go for "ignore the whole thing as malformed" (but raise an alert that there is a misconfiguration). > > Section 5.2.3 > > To discover a peer DOTS agent, the DHCPv4 client MUST include both > OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request > List Option [RFC2132]. > > Why is the v4 case a MUST but the v6 case was only MAY? I think that this was down to NAT being more likely in V4, and so the IP addresses take preference over the domain name returned. That said, I guess V6 could be a MUST as well. I do recall that I had issues with the DHCP client (Centos) for V4 - where I could not just ask for these options and get back a sensible response - there was an inherent assumption that it would normally be used for getting the DHCP IP/Name etc for the requesting interface, not for just requesting the information of some remote object. This was not an issue for V6. It maybe that I had to provide both options for it to work - I need to go back and test this out at some point. > > Section 6 > > 1. A DNS domain name is retrieved for each combination of interface > and address family. A DOTS agent has to determine the domain in > which it is located relying on dynamic means such as DHCP > (Section 5) . [...] > > Hmm, this may be worth a closer look. If I understand correctly, if > the procedures in Section 5 only give you a name, you're supposed to > use DNS to get IP addresses to talk to, from that name. So is this > procedure only applicable when the A/AAAA lookup fails? Otherwise I'm > not sure how you would get only a name but not full contact > information, from the section 5 procedure. Or, if the intent of "the > name is passed to a name resolution library" in Section 5 is to induce > the S-NAPTR lookups defined here, Section 5 should be more clear about that. My understanding was that we need to start with a seed domain that needs to be 'acquired' from somewhere. The standard domain that is allocated to a device may not be the same domain that handles the DOTS S-NAPTR - hence OPTION_V(4|6)_DOTS_RI responses can be used to get the DOTS relevant domain. > > a.example.net. > IN AAAA 2001:db8::1 > > I'm sure my INT-area colleagues will appreciate the IPv6 examples :) I firmed up on the final version of this after many failing attempts to get things right and working! Regards Jon From nobody Mon Sep 21 07:23: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 352FD3A0FB9; Mon, 21 Sep 2020 07:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5zC59ngyUErG; Mon, 21 Sep 2020 07:23:08 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F433A0FF7; Mon, 21 Sep 2020 07:23:08 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4Bw69Q6fkLz1ygd; Mon, 21 Sep 2020 16:23:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1600698186; bh=pArvfQV+TeZcrZfvuEoYv7ZIZt45mFCiCZkKUvMqseo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=oFRqWu1s498gja6YiibNZtAFcP5xkTdOquNWG1nXUgSV8E5Z8RgXGFwYFATYO1Rh1 /iyUbIkm6bRjJSl4fQgv/Ke5RvOIz4s/e0ZsQRlKRkoC6QAi+GKeussJHaP1f7q/fr NGT2jK+OyzMGZo+q/dlKNg5IY6snkzag1E2tuUwbs96me0U2ja/6k7navSUa93ekI0 b0sclU0FUmk6RaDxGrnRdV/mRUKTMK0k9cHDlW9/oEZuBPoggBCiHTDgXrzvRtTCai nWK4P/lBpRCLi2ha6Do3egkhC6dk55e3DyXEL+GSIIVKewwFMEbthYTeRay+lBPFmD AxyupKb+geUug== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4Bw69Q5d7wzDq7C; Mon, 21 Sep 2020 16:23:06 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-server-discovery.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-server-discovery-10 Thread-Index: AQHWjflrZ/JovkJmK0egVVTVgRvpC6ly8Izw Date: Mon, 21 Sep 2020 14:23:05 +0000 Message-ID: <17479_1600698186_5F68B74A_17479_404_1_787AE7BB302AE849A7480A190F8B933031543746@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200918202211.GI89563@kduck.mit.edu> In-Reply-To: <20200918202211.GI89563@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-server-discovery-10 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 14:23:11 -0000 Hi Ben,=20 Thank for the review.=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: vendredi 18 septembre 2020 22:22 > =C0=A0: draft-ietf-dots-server-discovery.all@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: AD review of draft-ietf-dots-server-discovery-10 >=20 > Hi all, >=20 > Despite the first half of the review basically being entirely nits, > there are some substantive comments in there later on. (Would it be > helpful if I tried harder to split the nits out into a separate > section in the future?) >=20 > Overall it's pretty straightforward, so no major issues left to > address; sorry for taking so long to get through it. >=20 >=20 > One thing that we should definitely fix before getting more eyes on > this document is that both TBD1 and TBD2 are overloaded -- we use > them to refer to the port assignments from the signal channel and > call home protocol assignments, but also for the DHCPv6 option > codes. [Med] We used TBA1/TBA2 in the core text for the codes to be assigned for D= HCPv6. Fixed the IANA section, though.=20=20 >=20 > Abstract >=20 > The first paragraph seems to be generic about all of DOTS, not > really very specific to discovery. I wonder if we want to just > remove the first paragraph or perhaps swap the order, the latter of > which might look like: >=20 > % This document specifies mechanisms to configure Districuted Denial > of % Service Open Threat Signaling (DOTS) clients with their DOTS > servers. > % The discovery procedure also covers the DOTS Signal Channel Call > Home. > % > % Knowing the appropriate DOTS server for a given location can be > useful % to engage mitigation actions even in cases where the DOTS > client % cannot localize the attack, but only knows that some > resources are % under attack and that help is needed. >=20 [Med] Works for me. Thanks.=20 > Section 1 >=20 > appropriate mitigation actions are required. Indeed, because the > lack of a common method to coordinate a real-time response among > involved actors and network domains inhibits the effectiveness of > DDoS attack mitigation, DOTS signal channel protocol > [I-D.ietf-dots-signal-channel] is meant to carry requests for > DDoS >=20 > nit: missing "the" before "DOTS signal channel protocol". >=20 [Med] Fixed. > attack mitigation, thereby reducing the impact of an attack and > leading to more efficient defensive actions in various deployment > scenarios such as those discussed in [I-D.ietf-dots-use-cases]. >=20 > nit: (also, this sentence is fairly long, though not necessarily > problematic.) [Med] Will consider splitting it.=20 >=20 > Moreover, DOTS clients can instruct a DOTS server to install > filtering rules by means of the DOTS data channel protocol > [I-D.ietf-dots-data-channel]. >=20 > nit: maybe "named filtering rules", since that is an important > aspect of how we interact with them. [Med] Indeed.=20 >=20 > [I-D.ietf-dots-architecture] specifies that the DOTS client may > be > provided with a list of DOTS servers; each associated with one or >=20 > nit: comma here, rather than semicolon. [Med] OK.=20 >=20 > This document assumes that security credentials to authenticate > DOTS > server(s) are provisioned to a DOTS client using a variety of > means > such as (but not limited to) those discussed in [RFC8572] or >=20 > nit: "using a variety of means" implies that all are used > concurrently; do we really mean "any of" or "one of"? [Med] Went for "one of". >=20 > Section 2 >=20 > The reader should be familiar with the terms defined in > [I-D.ietf-dots-architecture], [RFC3958], and > [I-D.ietf-dots-signal-call-home]. >=20 > A bit surprising to not see RFCx 8782/8783 in there, too :) [Med] That is normal. As the discovery does not require knowing about how t= he signals are working.=20=20 >=20 > Section 3 >=20 > o Many use cases discussed in [I-D.ietf-dots-use-cases] do > involve a > CPE device. Multiple CPEs, connected to distinct network >=20 > nit(?): I think "Many of the use cases" reads better. [Med] Fixed.=20 >=20 > providers may even be considered. It is intuitive to leverage > on >=20 > nits: comma after "providers"; s/on$// [Med] OK >=20 > o Resolving a DOTS server domain name offered by an upstream > transit > provider provisioned to a DOTS client into IP address(es) > require >=20 > nit: s/require/requires/ [Med] ACK. >=20 > o Some of the use cases may allow DOTS clients to have direct > communications with upstream DOTS servers; that is no DOTS > gateway >=20 > nit: comma/semicolon usage; let's go for "DOTS servers, that is, no > DOTS gateway" [Med] Done.=20 >=20 > is involved. Leveraging on existing features that do not > require >=20 > nit: s/Leveraging on/Leveraging/ [Med] Ack. >=20 > specific feature on the node embedding the DOTS client may > ease >=20 > nit: we use "features" and "feature" in this sentence, which makes > it a little hard to understand what's going on. Are the initial > "features" > more of "protocol behaviors"? [Med] Change to "Leveraging existing protocol behaviors that do not require= specific feature on the node embedding the DOTS client may ease DOTS deplo= yment." >=20 > Section 4 >=20 > A key point in the deployment of DOTS is the ability of network > operators to be able to configure DOTS clients with the correct > DOTS >=20 > nit: "ability" and "to be able to" are redundant (I suggest s/to be > able > to/to/) [Med] Indeed. >=20 > All DOTS clients MUST support at least one of the three > mechanisms > below to determine a DOTS server list. All DOTS clients SHOULD > implement all three, or as many as are practical for any specific > device (e.g., a CPE will support the first two mechanisms, a host > within a LAN will support the last two mechanisms, or an > application > server will support a local configuration. More samples are > discussed in Section 3), of these ways to discover DOTS servers, > in > order to facilitate the deployment of DOTS in large scale > environments: >=20 > nit: the way the parenthetical is structured is a bit unusual, with > a sentence break occurring within the parentheses (and leaving quite > a gap for processing in the middle of the thought "implement all > three of these ways"). It's probably okay to just make the "SHOULD > implement all three" a single standalone sentence, and leave the > clarification of when implementing all three is > infeasible/unnecessary to a follow-up sentence. [Med] Will split to ease the readability.=20 >=20 > server. When only DOTS server's IP addresses are > configured, > a reference identifier must also be configured for > authentication purposes. >=20 > Forestalling my common questions; good work! >=20 > * Automatic configuration (e.g., DHCP, an automation > system): > The DOTS client attempts to discover DOTS server(s) names > and/ > or addresses from DHCP, as described in Section 5. >=20 > We may get questions about this one, since it is apparently equating > DHCP with a (generic) "automation system". Perhaps we want to say > that the DHCP mechanism is used in the absence of manual or > automated explicit configuration? [Med] I deleted "an automation system". >=20 > the relevant DOTS server is obtained directly. Implementation > options may vary on a per device basis, as some devices may not > have > DNS capabilities and/or proper configuration. >=20 > nit: maybe "proper DNS configuration" or "proper resolver > configuration"? >=20 [Med] Yes. Changed to "proper DNS configuration". > combination of interface and address family. A DOTS client may > choose to perform the discovery procedure only for a desired > interface/address combination if the client does not wish to > discover >=20 > nit: I think "interface/address-family combination". [Med] ACK. >=20 > o Expiry of a lease associated with a discovered DOTS agent. >=20 > Is this specifically a DHCP lease, or a more generic concept? [Med] This is generic.=20=20 >=20 > Section 5 >=20 > As reported in Section 1.7.2 of [RFC6125]: >=20 > "few certification authorities issue server certificates based > on > IP addresses, but preliminary evidence indicates that such >=20 > I think the quote is actually "[s]ome", not "few" -- please check! [Med] I don't know how "few" ended there, but you are right.=20=20 >=20 > The list of the IP addresses returned by DHCP servers is > typically > used to fed the DOTS server selection procedure or to provide > DOTS >=20 > nit: s/fed/feed/ [Med] Ack. >=20 > for the DOTS Call Home. The DOTS client (or Call Home DOTS > server) > will then use the address selection specified in Section 4.3 of >=20 > nit: "address selection procedure" [Med] Ack.=20 >=20 > Let's consider that the DOTS server is reachable at > 2001:db8:122:300::1 while the Call Home DOTS client is > reachable > at 2001:db8:122:300::2. The DHCP server will then return one > DOTS > reference identifier and a list that includes both > 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting > DHCP > client. That list is passed to the DOTS client (or Call Home > DOTS > server) which will try to establish connections to the > addresses > of that list and destination port number TBD1 (or TBD2). As a > result, the DOTS client (or Call Home DOTS server) will select > 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server > (or > Call Home DOTS client). >=20 > I mostly expect pushback from TSV-area reviewers about giving the > allocated port numbers such importance in selecting the peer address > to use. [Med] We need to demux call-home from the base signal channel. We have text= in the call home draft to explain this. We can point the reviewers to that= section.=20 >=20 > Section 5.1.2 >=20 > format of this option is shown in Figure 5. As a reminder, this > format follows the guidelines for creating new DHCPv6 options > (Section 5.1 of [RFC7227]). >=20 > We need the reminder for the second option but not the first one? ;) [Med] Because we don't have a section to cite. There is only a list discuss= ed in 5.10 but we don't only need one name.=20 >=20 > Section 5.1.3 >=20 > are used to reach the peer DOTS agent. In other words, the name > conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying > resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a > response. >=20 > I'm not sure how much of this needs to end up in the document > itself, but can we walk through the scenarios here, especially when > the DNS-resolution addresses for the name in question differ from > the addresses in OPTION_V6_DOTS_ADDRESS? [Med] Actually, we want to avoid the aliasing issues discussed in RFC7227#s= ection-7 (the resolution may lead to different addresses if the logic for b= inding a client to server is not visible to "public" resolvers).=20 When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence. The cl= ient must not try to resolve the OPTION_V6_DOTS_RI.=20 I don't understand yet > why/how this scheme ends up being safe, and am hoping that you have > a head start over me on doing the analysis :) [Med] Returning both the address and the RI in the DHCP prevents redirectin= g a client to a "fake" server if the DNS queries are intercepted. We don't = have this issue if both the address and the RI are returned in DHCP.=20 >=20 > If the DHCP client receives OPTION_V6_DOTS_RI only, but > OPTION_V6_DOTS_RI option contains more than one name, as >=20 > nit: insert "the" at the start of the second line. [Med] deleted "option".=20 >=20 > If the DHCP client receives OPTION_V6_DOTS_RI only, but > OPTION_V6_DOTS_RI option contains more than one name, as > distinguished by the presence of multiple root labels, the DHCP > client MUST use only the first name. Once the name is validated >=20 > Is there a reason to make this "use the first one" vs. "ignore the > whole thing as malformed? [Med] If the message is ignored, the service won't be provided.=20 >=20 > (Section 8 of [RFC8415]), the name is passed to a name resolution > library. Moreover, that name is also used as a reference > identifier > for authentication purposes. >=20 > Hmm, I'm not seeing much in Section 8 specifically of RFC 8415 that > looks relevant here. Was perhaps a different document intended? [Med] It used to be "Section 8 of 3315", but since 3315 was obsoleted by 84= 15, it should read "Section 10 of 8415". Good catch. Thanks.=20 >=20 > Section 5.2.1 >=20 > A reference to 2132 here would be timely, not least for > understanding the figure. >=20 [Med] OK. > The values s1, s2, s3, etc. represent the domain name labels in > the > domain name encoding. >=20 > super-nitty-nit: maybe "the octets of the domain name labels"? IIUC > the RFC 2132 convention is to give such names to the individual > bytes of the DHCP option, but this wording implies that we are > naming labels, which are multi-byte (except for the root). [Med] I see your point but the figure uses the convention used in many othe= r dhc wg document. I will leave it. Bernie (dhc co-chair) reviewed the dhc= p part of the document and he didn't raise a comment about this.=20=20 >=20 > Section 5.2.2 >=20 > I wonder if anyone will complain that we are using a more "modern" > structure for the figure, instead of keeping with the "traditional" > DHCP option diagrams. [Med] At least, Bernie didn't complain when he reviewed the document.=20 >=20 > Section 5.2.3 >=20 > To discover a peer DOTS agent, the DHCPv4 client MUST include > both > OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter > Request > List Option [RFC2132]. >=20 > Why is the v4 case a MUST but the v6 case was only MAY? [Med] Because we start the v4 text with "To discover a peer DOTS agent,". W= e could align both, though.=20 >=20 > If the DHCP client receives more than one instance of > OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use > only the first instance of that option. >=20 > I think the parenthetical needs to be dropped, since in the previous > section we say that this is a concatenation-requiring option. [Med] Agree.=20 >=20 > If the DHCP client receives OPTION_V4_DOTS_RI only, but > OPTION_V4_DOTS_RI option contains more than one name, as > distinguished by the presence of multiple root labels, the DHCP > client MUST use only the first name. Once the name is validated > (Section 10 of [RFC8415]), the name is passed to a name > resolution > library. Moreover, that name is also used as a reference > identifier > for authentication purposes. >=20 > [same comments about "use first" as for v4] I see that here we > reference =A710, rather than 8, of RFC 8415, though it still doesn't > say much explicitly about a "validation procedure". [Med] The validation is basically check it follows Section 3.1 of [RFC1035]= and compression is not used.=20=20 >=20 > The diff between =A75.1.3 and 5.2.3 includes "(e.g., PKIX [RFRC6125])" > only in 5.1.3; it seems like it would also apply here. [Med] Indeed.=20 >=20 > The DHCP client MUST silently discard multicast and host loopback > addresses conveyed in OPTION_V4_DOTS_ADDRESS. >=20 > Can we put a reference for "multicast and host loopback" addresses > as we did for the v6 case? [Med] Sure.=20 >=20 > Section 6 >=20 > 1. A DNS domain name is retrieved for each combination of > interface > and address family. A DOTS agent has to determine the domain > in > which it is located relying on dynamic means such as DHCP > (Section 5) . [...] >=20 > Hmm, this may be worth a closer look. If I understand correctly, if > the procedures in Section 5 only give you a name, you're supposed to > use DNS to get IP addresses to talk to, from that name. So is this > procedure only applicable when the A/AAAA lookup fails? Otherwise > I'm not sure how you would get only a name but not full contact > information, from the section 5 procedure. Or, if the intent of > "the name is passed to a name resolution library" in Section 5 is to > induce the S-NAPTR lookups defined here, Section 5 should be more > clear about that. [Med] S-NAPTR lookups is covered by "... to a name resolution library". Nev= ertheless, some deployments may not require S-NAPTR lookups and A/AAAA reso= lution would be just fine.=20=20=20=20 >=20 > Once the DOTS agent has retrieved its DNS domain or discovered > the > peer DOTS agent name that needs to be resolved (e.g., Section 5), > an >=20 > (The parenthetical seems redundant with step (1).) [Med] Fixed.=20 >=20 > S-NAPTR lookup with 'DOTS' application service and the desired > [...] > This specification defines "DOTS" and "DOTS-CALL-HOME" as > application > service tags (Sections 9.4.1 and 9.4.2). It also defines >=20 > We should probably mention "DOTS-CALL-HOME" in both places, or just > say something generic like "the appropriate application service" in > the first instance, instead of only saying 'DOTS' the first time. >=20 [Med] Went for "the appropriate application service".=20 > a.example.net. > IN AAAA 2001:db8::1 >=20 > I'm sure my INT-area colleagues will appreciate the IPv6 examples :) >=20 > Section 8 >=20 > Having a clearly defined priority order for using the different > discovery mechanisms covers most of the potential security > considerations inherently, but I think some text is in order about > whether an attacker can block/modify traffic to force a "lower > priority" > mechanism to be used (but would not be able to modify the "higher > priority" mechanism's results with the same capabilities). [Med] Good point. I added the folliwng:=20 "An attacker may block some protocol messages (e.g., DHCP) to force the cli= ent to use a discovery mechanism with a lower priority. The security implic= ations of such attack are those inherent to the fallback discovery mechanis= m discussed in the following subsections. " >=20 > We may also want to reiterate that discovery results are scoped by > interface and address family, and that bad things can happen if you > use a result from one interface for traffic from a different > interface. [Med] We can add the following:=20 "The results of the discovery procedure are a function of the interface/add= ress family. Contacting a discovered DOTS server via an interface to which = it is not bind may exacerbate the delay required to establish a DOTS channe= l. Moreover, such behavior may reveal that a DOTS service is enabled by a D= OTS client domain and exposes the identity of the DOTS service provider (th= at can be inferred from the name and the destination IP address) to externa= l networks." >=20 > There are probably not particularly interesting privacy > considerations of advertising/exposing DOTS server names in these > various discovery mechanisms, but a brief section on privacy > considerations is likely in order regardless. [Med] The NEW text above touched on "privacy". I'm not sure what we need to= say more.=20 >=20 > Section 8.2 >=20 > The primary attack against the methods described in Section 6 is > one > that would lead to impersonation of a peer DOTS agent. An > attacker > could attempt to compromise the S-NAPTR resolution. The use of > mutual authentication makes it difficult to redirect a DOTS > client > (or a Call Home DOTS server) to an illegitimate DOTS server (or a > Call Home DOTS client). >=20 > IIUC this property only holds if the domain name used for > authenticating the peer (i.e., the input to the RFC 6125 procedures) > is the one used as input to the procedure in Section 6, not the > intermediate names produced during that procedure (e.g., > "example.net" as input and "a.example.net" > as intermediate, from Figure 10). I don't think we specify anywhere > that this must be the case, so on the face of it it seems that in > the absence of DNSSEC, an attacker spoofing DNS responses can > redirect the client to an arbitrary name controlled by the attacker, > for which the attacker has valid PKIX credentials. (We also allow > SRV-IDs for validation, so the SRV names are also affected.) I also > note that the analogous question for mail servers (whether they > authenticate as example.net or a.example.net) is a recurring source > of trouble, so our hand may be forced by deployment realities. [Med] Good point. Will update the text.=20 >=20 > Section 8.3 >=20 > I was going to say that we should reference the RFC 6763 security > considerations, too, but they are just saying the same things we > already say. >=20 > Section 12.2 >=20 > I expect at least one AD to suggest that the architecture draft > should be normative since we require it for terminology, but I don't > insist on changing its classification at this time. (Likewise for > Call Home.) >=20 [Med] Will let them as they are. Let's see if we will get comments on this.= =20 > -Ben ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 22 06:16: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 64D9C3A0D70; Tue, 22 Sep 2020 06:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GYCC5b06KN7l; Tue, 22 Sep 2020 06:16:24 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693E23A16AF; Tue, 22 Sep 2020 06:16:24 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4Bwhdz18K5z7vRr; Tue, 22 Sep 2020 15:16:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1600780583; bh=cO+p9MNPL7vjfbCEZn92XEJTO33jxHXY4qhQudPlpZg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=XDxFHktteZpi1OqVHEW0AXFnvNQY1Rqw/vZQ6ZdjKXZxXHtfcQ7F8/TrFo66sjuUO k7dirC2e/jo/mi0MKREDfGzNzOl2Of6vxeurWr8ZKC/10BBCw8V1V7SNJjiVA/mwl9 1XDpgxHNp9jqsv45tuTsaFUuNhX2k7+vmN9PnGdDhl1B8JyPTuj6Q4mxrlQQ6lxsQL OIwGr7VtZJTIVQnuqAik38qAb2DLJPMDDzFkQhbwZshAVEUu9+Txg4WWqsiAna2sOt WLabvUyJjns4PCnt10GeSwleddwkXwJTFEyP0Ss2aaw8fpmETfSSVEW/spvHt1Rfo+ ELCMjT3U38zRA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4Bwhdz01XpzCqkG; Tue, 22 Sep 2020 15:16:23 +0200 (CEST) From: To: Benjamin Kaduk CC: "dots@ietf.org" , "draft-ietf-dots-server-discovery.all@ietf.org" Thread-Topic: AD review of draft-ietf-dots-server-discovery-10 Thread-Index: AQHWjflrZ/JovkJmK0egVVTVgRvpC6ly8IzwgAG4O2A= Date: Tue, 22 Sep 2020 13:16:21 +0000 Message-ID: <30660_1600780583_5F69F927_30660_58_1_787AE7BB302AE849A7480A190F8B9330315442E8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200918202211.GI89563@kduck.mit.edu> <17479_1600698186_5F68B74A_17479_404_1_787AE7BB302AE849A7480A190F8B933031543746@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <17479_1600698186_5F68B74A_17479_404_1_787AE7BB302AE849A7480A190F8B933031543746@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-server-discovery-10 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, 22 Sep 2020 13:16:28 -0000 Hi Ben, all,=20 FWIW, a candidate version is available at:=20 https://github.com/boucadair/draft-ietf-dots-discovery/blob/master/draft-ie= tf-dots-server-discovery.txt The diff can be seen here: https://github.com/boucadair/draft-ietf-dots-dis= covery/commit/1fd6b52c9347ea8e59005533b175b62ea6928237=20 Cheers, Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: lundi 21 septembre 2020 16:23 > =C0=A0: Benjamin Kaduk ; draft-ietf-dots-server- > discovery.all@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: RE: AD review of draft-ietf-dots-server-discovery-10 >=20 > Hi Ben, >=20 > Thank for the review. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] Envoy=E9=A0: vendredi 18 > > septembre 2020 22:22 =C0=A0: draft-ietf-dots-server- > discovery.all@ietf.org > > Cc=A0: dots@ietf.org > > Objet=A0: AD review of draft-ietf-dots-server-discovery-10 > > > > Hi all, > > > > Despite the first half of the review basically being entirely > nits, > > there are some substantive comments in there later on. (Would it > be > > helpful if I tried harder to split the nits out into a separate > > section in the future?) > > > > Overall it's pretty straightforward, so no major issues left to > > address; sorry for taking so long to get through it. > > > > > > One thing that we should definitely fix before getting more eyes > on > > this document is that both TBD1 and TBD2 are overloaded -- we use > them > > to refer to the port assignments from the signal channel and call > home > > protocol assignments, but also for the DHCPv6 option codes. >=20 > [Med] We used TBA1/TBA2 in the core text for the codes to be > assigned for DHCPv6. Fixed the IANA section, though. >=20 > > > > Abstract > > > > The first paragraph seems to be generic about all of DOTS, not > really > > very specific to discovery. I wonder if we want to just remove > the > > first paragraph or perhaps swap the order, the latter of which > might > > look like: > > > > % This document specifies mechanisms to configure Districuted > Denial > > of % Service Open Threat Signaling (DOTS) clients with their DOTS > > servers. > > % The discovery procedure also covers the DOTS Signal Channel Call > > Home. > > % > > % Knowing the appropriate DOTS server for a given location can be > > useful % to engage mitigation actions even in cases where the DOTS > > client % cannot localize the attack, but only knows that some > > resources are % under attack and that help is needed. > > >=20 > [Med] Works for me. Thanks. >=20 > > Section 1 > > > > appropriate mitigation actions are required. Indeed, because > the > > lack of a common method to coordinate a real-time response > among > > involved actors and network domains inhibits the effectiveness > of > > DDoS attack mitigation, DOTS signal channel protocol > > [I-D.ietf-dots-signal-channel] is meant to carry requests for > DDoS > > > > nit: missing "the" before "DOTS signal channel protocol". > > >=20 > [Med] Fixed. >=20 > > attack mitigation, thereby reducing the impact of an attack and > > leading to more efficient defensive actions in various > deployment > > scenarios such as those discussed in [I-D.ietf-dots-use-cases]. > > > > nit: (also, this sentence is fairly long, though not necessarily > > problematic.) >=20 > [Med] Will consider splitting it. >=20 > > > > Moreover, DOTS clients can instruct a DOTS server to install > > filtering rules by means of the DOTS data channel protocol > > [I-D.ietf-dots-data-channel]. > > > > nit: maybe "named filtering rules", since that is an important > aspect > > of how we interact with them. >=20 > [Med] Indeed. >=20 > > > > [I-D.ietf-dots-architecture] specifies that the DOTS client may > be > > provided with a list of DOTS servers; each associated with one > or > > > > nit: comma here, rather than semicolon. >=20 > [Med] OK. >=20 > > > > This document assumes that security credentials to authenticate > > DOTS > > server(s) are provisioned to a DOTS client using a variety of > means > > such as (but not limited to) those discussed in [RFC8572] or > > > > nit: "using a variety of means" implies that all are used > > concurrently; do we really mean "any of" or "one of"? >=20 > [Med] Went for "one of". >=20 > > > > Section 2 > > > > The reader should be familiar with the terms defined in > > [I-D.ietf-dots-architecture], [RFC3958], and > > [I-D.ietf-dots-signal-call-home]. > > > > A bit surprising to not see RFCx 8782/8783 in there, too :) >=20 > [Med] That is normal. As the discovery does not require knowing > about how the signals are working. >=20 > > > > Section 3 > > > > o Many use cases discussed in [I-D.ietf-dots-use-cases] do > involve > > a > > CPE device. Multiple CPEs, connected to distinct network > > > > nit(?): I think "Many of the use cases" reads better. >=20 > [Med] Fixed. >=20 > > > > providers may even be considered. It is intuitive to > leverage > > on > > > > nits: comma after "providers"; s/on$// >=20 > [Med] OK >=20 > > > > o Resolving a DOTS server domain name offered by an upstream > > transit > > provider provisioned to a DOTS client into IP address(es) > > require > > > > nit: s/require/requires/ >=20 > [Med] ACK. >=20 > > > > o Some of the use cases may allow DOTS clients to have direct > > communications with upstream DOTS servers; that is no DOTS > > gateway > > > > nit: comma/semicolon usage; let's go for "DOTS servers, that is, > no > > DOTS gateway" >=20 > [Med] Done. >=20 > > > > is involved. Leveraging on existing features that do not > > require > > > > nit: s/Leveraging on/Leveraging/ >=20 > [Med] Ack. >=20 > > > > specific feature on the node embedding the DOTS client may > ease > > > > nit: we use "features" and "feature" in this sentence, which makes > it > > a little hard to understand what's going on. Are the initial > > "features" > > more of "protocol behaviors"? >=20 > [Med] Change to "Leveraging existing protocol behaviors that do not > require specific feature on the node embedding the DOTS client may > ease DOTS deployment." >=20 > > > > Section 4 > > > > A key point in the deployment of DOTS is the ability of network > > operators to be able to configure DOTS clients with the correct > > DOTS > > > > nit: "ability" and "to be able to" are redundant (I suggest s/to > be > > able > > to/to/) >=20 > [Med] Indeed. >=20 > > > > All DOTS clients MUST support at least one of the three > mechanisms > > below to determine a DOTS server list. All DOTS clients SHOULD > > implement all three, or as many as are practical for any > specific > > device (e.g., a CPE will support the first two mechanisms, a > host > > within a LAN will support the last two mechanisms, or an > > application > > server will support a local configuration. More samples are > > discussed in Section 3), of these ways to discover DOTS > servers, in > > order to facilitate the deployment of DOTS in large scale > > environments: > > > > nit: the way the parenthetical is structured is a bit unusual, > with a > > sentence break occurring within the parentheses (and leaving quite > a > > gap for processing in the middle of the thought "implement all > three > > of these ways"). It's probably okay to just make the "SHOULD > > implement all three" a single standalone sentence, and leave the > > clarification of when implementing all three is > infeasible/unnecessary > > to a follow-up sentence. >=20 > [Med] Will split to ease the readability. >=20 > > > > server. When only DOTS server's IP addresses are > > configured, > > a reference identifier must also be configured for > > authentication purposes. > > > > Forestalling my common questions; good work! > > > > * Automatic configuration (e.g., DHCP, an automation > > system): > > The DOTS client attempts to discover DOTS server(s) > names > > and/ > > or addresses from DHCP, as described in Section 5. > > > > We may get questions about this one, since it is apparently > equating > > DHCP with a (generic) "automation system". Perhaps we want to say > > that the DHCP mechanism is used in the absence of manual or > automated > > explicit configuration? >=20 > [Med] I deleted "an automation system". >=20 > > > > the relevant DOTS server is obtained directly. Implementation > > options may vary on a per device basis, as some devices may not > > have > > DNS capabilities and/or proper configuration. > > > > nit: maybe "proper DNS configuration" or "proper resolver > > configuration"? > > >=20 > [Med] Yes. Changed to "proper DNS configuration". >=20 > > combination of interface and address family. A DOTS client may > > choose to perform the discovery procedure only for a desired > > interface/address combination if the client does not wish to > > discover > > > > nit: I think "interface/address-family combination". >=20 > [Med] ACK. >=20 > > > > o Expiry of a lease associated with a discovered DOTS agent. > > > > Is this specifically a DHCP lease, or a more generic concept? >=20 > [Med] This is generic. >=20 > > > > Section 5 > > > > As reported in Section 1.7.2 of [RFC6125]: > > > > "few certification authorities issue server certificates > based > > on > > IP addresses, but preliminary evidence indicates that such > > > > I think the quote is actually "[s]ome", not "few" -- please check! >=20 > [Med] I don't know how "few" ended there, but you are right. >=20 > > > > The list of the IP addresses returned by DHCP servers is > typically > > used to fed the DOTS server selection procedure or to provide > DOTS > > > > nit: s/fed/feed/ >=20 > [Med] Ack. >=20 > > > > for the DOTS Call Home. The DOTS client (or Call Home DOTS > > server) > > will then use the address selection specified in Section 4.3 of > > > > nit: "address selection procedure" >=20 > [Med] Ack. >=20 > > > > Let's consider that the DOTS server is reachable at > > 2001:db8:122:300::1 while the Call Home DOTS client is > reachable > > at 2001:db8:122:300::2. The DHCP server will then return > one > > DOTS > > reference identifier and a list that includes both > > 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting > DHCP > > client. That list is passed to the DOTS client (or Call > Home > > DOTS > > server) which will try to establish connections to the > addresses > > of that list and destination port number TBD1 (or TBD2). As > a > > result, the DOTS client (or Call Home DOTS server) will > select > > 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS > server > > (or > > Call Home DOTS client). > > > > I mostly expect pushback from TSV-area reviewers about giving the > > allocated port numbers such importance in selecting the peer > address > > to use. >=20 > [Med] We need to demux call-home from the base signal channel. We > have text in the call home draft to explain this. We can point the > reviewers to that section. >=20 > > > > Section 5.1.2 > > > > format of this option is shown in Figure 5. As a reminder, > this > > format follows the guidelines for creating new DHCPv6 options > > (Section 5.1 of [RFC7227]). > > > > We need the reminder for the second option but not the first one? > ;) >=20 > [Med] Because we don't have a section to cite. There is only a list > discussed in 5.10 but we don't only need one name. >=20 > > > > Section 5.1.3 > > > > are used to reach the peer DOTS agent. In other words, the > name > > conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying > > resolution library in the presence of OPTION_V6_DOTS_ADDRESS in > a > > response. > > > > I'm not sure how much of this needs to end up in the document > itself, > > but can we walk through the scenarios here, especially when the > > DNS-resolution addresses for the name in question differ from the > > addresses in OPTION_V6_DOTS_ADDRESS? >=20 > [Med] Actually, we want to avoid the aliasing issues discussed in > RFC7227#section-7 (the resolution may lead to different addresses if > the logic for binding a client to server is not visible to "public" > resolvers). >=20 > When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence. > The client must not try to resolve the OPTION_V6_DOTS_RI. >=20 > I don't understand yet > > why/how this scheme ends up being safe, and am hoping that you > have a > > head start over me on doing the analysis :) >=20 > [Med] Returning both the address and the RI in the DHCP prevents > redirecting a client to a "fake" server if the DNS queries are > intercepted. We don't have this issue if both the address and the RI > are returned in DHCP. >=20 > > > > If the DHCP client receives OPTION_V6_DOTS_RI only, but > > OPTION_V6_DOTS_RI option contains more than one name, as > > > > nit: insert "the" at the start of the second line. >=20 > [Med] deleted "option". >=20 > > > > If the DHCP client receives OPTION_V6_DOTS_RI only, but > > OPTION_V6_DOTS_RI option contains more than one name, as > > distinguished by the presence of multiple root labels, the DHCP > > client MUST use only the first name. Once the name is > validated > > > > Is there a reason to make this "use the first one" vs. "ignore the > > whole thing as malformed? >=20 > [Med] If the message is ignored, the service won't be provided. >=20 > > > > (Section 8 of [RFC8415]), the name is passed to a name > resolution > > library. Moreover, that name is also used as a reference > > identifier > > for authentication purposes. > > > > Hmm, I'm not seeing much in Section 8 specifically of RFC 8415 > that > > looks relevant here. Was perhaps a different document intended? >=20 > [Med] It used to be "Section 8 of 3315", but since 3315 was > obsoleted by 8415, it should read "Section 10 of 8415". Good catch. > Thanks. >=20 > > > > Section 5.2.1 > > > > A reference to 2132 here would be timely, not least for > understanding > > the figure. > > >=20 > [Med] OK. >=20 > > The values s1, s2, s3, etc. represent the domain name labels > in > > the > > domain name encoding. > > > > super-nitty-nit: maybe "the octets of the domain name labels"? > IIUC > > the RFC 2132 convention is to give such names to the individual > bytes > > of the DHCP option, but this wording implies that we are naming > > labels, which are multi-byte (except for the root). >=20 > [Med] I see your point but the figure uses the convention used in > many other dhc wg document. I will leave it. Bernie (dhc co-chair) > reviewed the dhcp part of the document and he didn't raise a comment > about this. >=20 > > > > Section 5.2.2 > > > > I wonder if anyone will complain that we are using a more "modern" > > structure for the figure, instead of keeping with the > "traditional" > > DHCP option diagrams. >=20 > [Med] At least, Bernie didn't complain when he reviewed the > document. >=20 > > > > Section 5.2.3 > > > > To discover a peer DOTS agent, the DHCPv4 client MUST include > both > > OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter > Request > > List Option [RFC2132]. > > > > Why is the v4 case a MUST but the v6 case was only MAY? >=20 > [Med] Because we start the v4 text with "To discover a peer DOTS > agent,". We could align both, though. >=20 > > > > If the DHCP client receives more than one instance of > > OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST > use > > only the first instance of that option. > > > > I think the parenthetical needs to be dropped, since in the > previous > > section we say that this is a concatenation-requiring option. >=20 > [Med] Agree. >=20 > > > > If the DHCP client receives OPTION_V4_DOTS_RI only, but > > OPTION_V4_DOTS_RI option contains more than one name, as > > distinguished by the presence of multiple root labels, the DHCP > > client MUST use only the first name. Once the name is > validated > > (Section 10 of [RFC8415]), the name is passed to a name > resolution > > library. Moreover, that name is also used as a reference > > identifier > > for authentication purposes. > > > > [same comments about "use first" as for v4] I see that here we > > reference =A710, rather than 8, of RFC 8415, though it still doesn't > say > > much explicitly about a "validation procedure". >=20 > [Med] The validation is basically check it follows Section 3.1 of > [RFC1035] and compression is not used. >=20 > > > > The diff between =A75.1.3 and 5.2.3 includes "(e.g., PKIX > [RFRC6125])" > > only in 5.1.3; it seems like it would also apply here. >=20 > [Med] Indeed. >=20 > > > > The DHCP client MUST silently discard multicast and host > loopback > > addresses conveyed in OPTION_V4_DOTS_ADDRESS. > > > > Can we put a reference for "multicast and host loopback" addresses > as > > we did for the v6 case? >=20 > [Med] Sure. >=20 > > > > Section 6 > > > > 1. A DNS domain name is retrieved for each combination of > > interface > > and address family. A DOTS agent has to determine the > domain > > in > > which it is located relying on dynamic means such as DHCP > > (Section 5) . [...] > > > > Hmm, this may be worth a closer look. If I understand correctly, > if > > the procedures in Section 5 only give you a name, you're supposed > to > > use DNS to get IP addresses to talk to, from that name. So is > this > > procedure only applicable when the A/AAAA lookup fails? Otherwise > I'm > > not sure how you would get only a name but not full contact > > information, from the section 5 procedure. Or, if the intent of > "the > > name is passed to a name resolution library" in Section 5 is to > induce > > the S-NAPTR lookups defined here, Section 5 should be more clear > about > > that. >=20 > [Med] S-NAPTR lookups is covered by "... to a name resolution > library". Nevertheless, some deployments may not require S-NAPTR > lookups and A/AAAA resolution would be just fine. >=20 > > > > Once the DOTS agent has retrieved its DNS domain or discovered > the > > peer DOTS agent name that needs to be resolved (e.g., Section > 5), > > an > > > > (The parenthetical seems redundant with step (1).) >=20 > [Med] Fixed. >=20 > > > > S-NAPTR lookup with 'DOTS' application service and the desired > > [...] > > This specification defines "DOTS" and "DOTS-CALL-HOME" as > > application > > service tags (Sections 9.4.1 and 9.4.2). It also defines > > > > We should probably mention "DOTS-CALL-HOME" in both places, or > just > > say something generic like "the appropriate application service" > in > > the first instance, instead of only saying 'DOTS' the first time. > > >=20 > [Med] Went for "the appropriate application service". >=20 > > a.example.net. > > IN AAAA 2001:db8::1 > > > > I'm sure my INT-area colleagues will appreciate the IPv6 examples > :) > > > > Section 8 > > > > Having a clearly defined priority order for using the different > > discovery mechanisms covers most of the potential security > > considerations inherently, but I think some text is in order about > > whether an attacker can block/modify traffic to force a "lower > > priority" > > mechanism to be used (but would not be able to modify the "higher > > priority" mechanism's results with the same capabilities). >=20 > [Med] Good point. I added the folliwng: >=20 > "An attacker may block some protocol messages (e.g., DHCP) to force > the client to use a discovery mechanism with a lower priority. The > security implications of such attack are those inherent to the > fallback discovery mechanism discussed in the following subsections. > " >=20 > > > > We may also want to reiterate that discovery results are scoped by > > interface and address family, and that bad things can happen if > you > > use a result from one interface for traffic from a different > > interface. >=20 > [Med] We can add the following: >=20 > "The results of the discovery procedure are a function of the > interface/address family. Contacting a discovered DOTS server via an > interface to which it is not bind may exacerbate the delay required > to establish a DOTS channel. Moreover, such behavior may reveal that > a DOTS service is enabled by a DOTS client domain and exposes the > identity of the DOTS service provider (that can be inferred from the > name and the destination IP address) to external networks." >=20 > > > > There are probably not particularly interesting privacy > considerations > > of advertising/exposing DOTS server names in these various > discovery > > mechanisms, but a brief section on privacy considerations is > likely in > > order regardless. >=20 > [Med] The NEW text above touched on "privacy". I'm not sure what we > need to say more. >=20 > > > > Section 8.2 > > > > The primary attack against the methods described in Section 6 > is > > one > > that would lead to impersonation of a peer DOTS agent. An > attacker > > could attempt to compromise the S-NAPTR resolution. The use of > > mutual authentication makes it difficult to redirect a DOTS > client > > (or a Call Home DOTS server) to an illegitimate DOTS server (or > a > > Call Home DOTS client). > > > > IIUC this property only holds if the domain name used for > > authenticating the peer (i.e., the input to the RFC 6125 > procedures) > > is the one used as input to the procedure in Section 6, not the > > intermediate names produced during that procedure (e.g., > "example.net" > > as input and "a.example.net" > > as intermediate, from Figure 10). I don't think we specify > anywhere > > that this must be the case, so on the face of it it seems that in > the > > absence of DNSSEC, an attacker spoofing DNS responses can redirect > the > > client to an arbitrary name controlled by the attacker, for which > the > > attacker has valid PKIX credentials. (We also allow SRV-IDs for > > validation, so the SRV names are also affected.) I also note that > the > > analogous question for mail servers (whether they authenticate as > > example.net or a.example.net) is a recurring source of trouble, so > our > > hand may be forced by deployment realities. >=20 > [Med] Good point. Will update the text. >=20 > > > > Section 8.3 > > > > I was going to say that we should reference the RFC 6763 security > > considerations, too, but they are just saying the same things we > > already say. > > > > Section 12.2 > > > > I expect at least one AD to suggest that the architecture draft > should > > be normative since we require it for terminology, but I don't > insist > > on changing its classification at this time. (Likewise for Call > > Home.) > > >=20 > [Med] Will let them as they are. Let's see if we will get comments > on this. >=20 > > -Ben ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 23 18:38: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 006EE3A167A; Wed, 23 Sep 2020 18:38:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ebben Aries via Datatracker To: Cc: dots@ietf.org, draft-ietf-dots-rfc8782-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160091148495.1709.10744527350560713534@ietfa.amsl.com> Reply-To: Ebben Aries Date: Wed, 23 Sep 2020 18:38:04 -0700 Archived-At: Subject: [Dots] Yangdoctors early review of draft-ietf-dots-rfc8782-bis-00 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, 24 Sep 2020 01:38:05 -0000 Reviewer: Ebben Aries Review result: On the Right Track 2 modules in this draft: - ietf-dots-signal-channel@2020-07-02.yang - iana-dots-signal-channel@2020-05-28.yang YANG compiler errors or warnings (pyang 2.3.2, yanglint 1.9.2) - No compiler errors or warnings however pyang 2.3.2 is currently the only compiler verified to emit YANG sx:structure data in tree format. Instance data could not yet easily be validated given the current linters/compilers. General comments on the draft/modules: ---------------------------------------- The modules defined in this draft are an update replacement to those defined in RFC8782 with only 1 being updated from the prior publication. - ietf-dots-signal-channel@2020-05-28.yang (updated) - iana-dots-signal-channel@2020-05-28.yang - First, I share some of the same comments as the previous review in that it takes some additional thought on modeling structures for alternate protocol communications with the YANG language. Overall, I think this is likely fine but also question where the draft/RFC specification outlines rules that are not conveyed within the data-model. Some examples include specifying mandatory attributes but not making use of the YANG 'mandatory' statement. Other cases are stating the intent of reserved or invalid integers but not putting the same restrictions on the types under a given data node. Overall this means that you cannot validate the instance/payload data according to the data-model alone. - Previous review suggested the main edits required switching the top-level container 'dots-signal'. This has now been fulfilled by that of an sx:structure in this revision. - A recent discussion among YANG doctors suggests the use of normative language (RFC2119) in YANG description statements. For example 'should' => 'SHOULD', 'must' => 'MUST', etc... A benefit to this approach is RFC comprehension even when the module is stripped from the source document it is contained under. - (draft) L887 nit: "As a reminder, the prefix length must be less than or equal to 32 (for IPv4) for 128 (for IPv6)" Module ietf-dots-signal-channel: ---------------------------------------- - IMO, the module prefix 'signal' is too generic for what is specific to message payload over a protocol that uses CoAP. Looking at all the published RFCs for dots, we have the same use of generic prefixes. Since the prefix is of local scope, it is not an entirely large issue but in hindsight should have had some better consistency especially when the recommendation to module importers is to utilize the defined prefix of said module. - This module imports and references 'ietf-dots-data-channel' as prefix 'ietf-data'. Not only is this too generic as I mentioned above, it is not using the suggested prefix of 'data-channel' (which is also too generic) as defined within that module (RFC7950 Section 7.1.4) "When used inside the "module" statement, the "prefix" statement defines the prefix suggested to be used when this module is imported." - Minor nit: It appears all author email addresses have been updated since the RFC8782 variant replacing '@' with '&' Module iana-dots-signal-channel: ---------------------------------------- - Similar to what I mention above regarding the module prefix, we use a generic 'iana-signal' prefix here which is inconsistent and not descriptive of the overall intent of the module. Overall, I'm not sure if the other referenced and published DOTS YANG modules went through a YD review but the comments above really should be addressed in a new revision of those modules. Once the above is addressed and possibly some discussion around when type restrictions are not conveyed within the model, it is probably on the right track. Since this is not the usual use of YANG in the context of YD reviews, it is a bit of an on the fly analysis which may require some additional discussion among other YANG doctors. From nobody Thu Sep 24 01:36: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 CD9C93A09DB; Thu, 24 Sep 2020 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 K_bc4ECQJKXp; Thu, 24 Sep 2020 01:36:14 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA76A3A09D8; Thu, 24 Sep 2020 01:36:10 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4BxpKj1v72z4wlf; Thu, 24 Sep 2020 10:36:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1600936569; bh=d6OW6TwinyhpDmdeRDcJTtLuduJhHT848EGqInsWvzM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=k4sYfNvhzBM0qzVE6wkS/9AsGHptq6rKWL03so/04jqoy8dk+jr73X1wCFJxylTmv +SRMKKmL3IqBBULdDzVaSo59T5rVe3NMSnIqsYn/lb1Ad3pn8CmRkaYL94FJ+i5y5x sibrwUXoRnLsXHXfQcAIlonM0aGF7sgZoC9nkQew50oamtOCWYvymxM7VY7e6uf4e2 Xx7d88VhTUlSyw/2xlYubB5nScFqI+7c6qVLWQZ4R3ENnIQJs3zME4383uqkJUj1Cu NvXZ0Tw3Zi9ZVPNbWTkaBBSeev8pBtfWhz+cAwatbQg2p/+X95i2oowi6KuC+m7j7h ZmCyvA9k2DLPg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4BxpKj17P1zDq7L; Thu, 24 Sep 2020 10:36:09 +0200 (CEST) From: To: Ebben Aries , "yang-doctors@ietf.org" CC: "dots@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-dots-rfc8782-bis-00 Thread-Index: AQHWkhNaJj3ct9KtuU+sGJdrsGqwE6l3VNxQ Date: Thu, 24 Sep 2020 08:36:08 +0000 Message-ID: <18277_1600936569_5F6C5A79_18277_298_1_787AE7BB302AE849A7480A190F8B9330315459EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160091148495.1709.10744527350560713534@ietfa.amsl.com> In-Reply-To: <160091148495.1709.10744527350560713534@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Yangdoctors early review of draft-ietf-dots-rfc8782-bis-00 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, 24 Sep 2020 08:36:16 -0000 SGkgRWJiZW4sIGFsbCwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNl ZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gRGXCoDogRWJiZW4gQXJpZXMgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBp ZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBqZXVkaSAyNCBzZXB0ZW1icmUgMjAyMCAwMzozOA0KPiDD gMKgOiB5YW5nLWRvY3RvcnNAaWV0Zi5vcmcNCj4gQ2PCoDogZG90c0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1kb3RzLXJmYzg3ODItYmlzLmFsbEBpZXRmLm9yZw0KPiBPYmpldMKgOiBZYW5nZG9jdG9y cyBlYXJseSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLXJmYzg3ODItYmlzLTAwDQo+IA0KPiBS ZXZpZXdlcjogRWJiZW4gQXJpZXMNCj4gUmV2aWV3IHJlc3VsdDogT24gdGhlIFJpZ2h0IFRyYWNr DQo+IA0KPiAyIG1vZHVsZXMgaW4gdGhpcyBkcmFmdDoNCj4gLSBpZXRmLWRvdHMtc2lnbmFsLWNo YW5uZWxAMjAyMC0wNy0wMi55YW5nDQo+IC0gaWFuYS1kb3RzLXNpZ25hbC1jaGFubmVsQDIwMjAt MDUtMjgueWFuZw0KPiANCj4gWUFORyBjb21waWxlciBlcnJvcnMgb3Igd2FybmluZ3MgKHB5YW5n IDIuMy4yLCB5YW5nbGludCAxLjkuMikNCj4gLSBObyBjb21waWxlciBlcnJvcnMgb3Igd2Fybmlu Z3MgaG93ZXZlciBweWFuZyAyLjMuMiBpcyBjdXJyZW50bHkNCj4gdGhlIG9ubHkNCj4gICBjb21w aWxlciB2ZXJpZmllZCB0byBlbWl0IFlBTkcgc3g6c3RydWN0dXJlIGRhdGEgaW4gdHJlZSBmb3Jt YXQuDQo+IEluc3RhbmNlDQoNCltNZWRdIEkgY29uZmlybSB0aGlzIGlzIHdoYXQgd2UgYXJlIHVz aW5nLiANCg0KPiAgIGRhdGEgY291bGQgbm90IHlldCBlYXNpbHkgYmUgdmFsaWRhdGVkIGdpdmVu IHRoZSBjdXJyZW50DQo+IGxpbnRlcnMvY29tcGlsZXJzLg0KPiANCj4gR2VuZXJhbCBjb21tZW50 cyBvbiB0aGUgZHJhZnQvbW9kdWxlczoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBUaGUgbW9kdWxlcyBkZWZpbmVkIGluIHRoaXMgZHJhZnQgYXJlIGFuIHVw ZGF0ZSByZXBsYWNlbWVudCB0byB0aG9zZQ0KPiBkZWZpbmVkIGluIFJGQzg3ODIgd2l0aCBvbmx5 IDEgYmVpbmcgdXBkYXRlZCBmcm9tIHRoZSBwcmlvcg0KPiBwdWJsaWNhdGlvbi4NCj4gICAtIGll dGYtZG90cy1zaWduYWwtY2hhbm5lbEAyMDIwLTA1LTI4LnlhbmcgKHVwZGF0ZWQpDQo+ICAgLSBp YW5hLWRvdHMtc2lnbmFsLWNoYW5uZWxAMjAyMC0wNS0yOC55YW5nDQo+IA0KPiAtIEZpcnN0LCBJ IHNoYXJlIHNvbWUgb2YgdGhlIHNhbWUgY29tbWVudHMgYXMgdGhlIHByZXZpb3VzIHJldmlldyBp bg0KPiB0aGF0IGl0DQo+ICAgdGFrZXMgc29tZSBhZGRpdGlvbmFsIHRob3VnaHQgb24gbW9kZWxp bmcgc3RydWN0dXJlcyBmb3IgYWx0ZXJuYXRlDQo+IHByb3RvY29sDQo+ICAgY29tbXVuaWNhdGlv bnMgd2l0aCB0aGUgWUFORyBsYW5ndWFnZS4gIE92ZXJhbGwsIEkgdGhpbmsgdGhpcyBpcw0KPiBs aWtlbHkgZmluZQ0KPiAgIGJ1dCBhbHNvIHF1ZXN0aW9uIHdoZXJlIHRoZSBkcmFmdC9SRkMgc3Bl Y2lmaWNhdGlvbiBvdXRsaW5lcyBydWxlcw0KPiB0aGF0IGFyZQ0KPiAgIG5vdCBjb252ZXllZCB3 aXRoaW4gdGhlIGRhdGEtbW9kZWwuICBTb21lIGV4YW1wbGVzIGluY2x1ZGUNCj4gc3BlY2lmeWlu Zw0KPiAgIG1hbmRhdG9yeSBhdHRyaWJ1dGVzIGJ1dCBub3QgbWFraW5nIHVzZSBvZiB0aGUgWUFO RyAnbWFuZGF0b3J5Jw0KPiBzdGF0ZW1lbnQuDQoNCltNZWRdIFdlIGFyZSB1c2luZyAibWFuZGF0 b3J5IiBzdGF0ZW1lbnRzIHdoZW4gdGhpcyBtYWtlcyBzZW5zZSAoZS5nLiwgYWx0LXNlcnZlciwg aGItc3RhdHVzKS4gSXQgaXMgbm90IHVzZWQgZm9yIHNvbWUgYXR0cmlidXRlcyB0aGF0IG1heSBh cHBlYXIgaW4gYm90aCBkaXJlY3Rpb25zLCBidXQgYXJlIG5vdCBtYW5kYXRvcnkgaW4gb25lIGRp cmVjdGlvbi4gRm9yIGV4YW1wbGUsICJsaWZldGltZSIgaXMgbWFuZGF0b3J5IGluIGEgbWl0aWdh dGlvbiByZXF1ZXN0LCBidXQgaXQgaXMgd2hlbiB0aGUgc2VydmVyIHJlcGxpZXMgd2l0aCBhIGNv bmZsaWN0IG1lc3NhZ2UuIA0KDQpGV0lXLCBhIGNvbnN0cmFpbnQgd2UgaGFkIGlzIHRvIHJldXNl IGFzIG11Y2ggYXMgcG9zc2libGUgdGhlIHNhbWUgQ0JPUiBrZXkvYXR0cmlidXRlIG5hbWVzLiBU aGlzIGlzIG5vdCBwb3NzaWJsZSBpZiB3ZSBvdmVybG9hZCB0aGUgbW9kdWxlIHdpdGggImNob2lj ZSJzOg0KDQo9PQ0KICAgRWFjaCAiY2FzZSIgbWF5DQogICBjb250YWluIG11bHRpcGxlIG5vZGVz LCBidXQgZWFjaCBub2RlIG1heSBhcHBlYXIgaW4gb25seSBvbmUgImNhc2UiDQogICB1bmRlciBh ICJjaG9pY2UiLg0KPT0NCg0KVGhpcyBpcyB3aHkgd2hhdCBpcyBub3JtYXRpdmUgZm9yIGFuIGlt cGxlbWVudGF0aW9uIGlzIHRoZSBjb3JlIG9mIHRoZSBzcGVjaWZpY2F0aW9uIG5vdCB0aGUgWUFO RyBtb2R1bGUgaXRzZWxmLg0KDQo+ICAgT3RoZXIgY2FzZXMgYXJlIHN0YXRpbmcgdGhlIGludGVu dCBvZiByZXNlcnZlZCBvciBpbnZhbGlkIGludGVnZXJzDQo+IGJ1dCBub3QNCj4gICBwdXR0aW5n IHRoZSBzYW1lIHJlc3RyaWN0aW9ucyBvbiB0aGUgdHlwZXMgdW5kZXIgYSBnaXZlbiBkYXRhDQo+ IG5vZGUuIA0KDQpbTWVkXSBDYW4geW91IHBsZWFzZSBpbmRpY2F0ZSB3aGljaCBkYXRhIG5vZGUg YXJlIHlvdSByZWZlcnJpbmcgdG8/IFRoYW5rcy4NCg0KIE92ZXJhbGwNCj4gICB0aGlzIG1lYW5z IHRoYXQgeW91IGNhbm5vdCB2YWxpZGF0ZSB0aGUgaW5zdGFuY2UvcGF5bG9hZCBkYXRhDQo+IGFj Y29yZGluZyB0bw0KPiAgIHRoZSBkYXRhLW1vZGVsIGFsb25lLg0KDQpbTWVkXSBBZ3JlZS4gVGhl IGRhdGEgbW9kZWwgYWxvbmUgaXMgbm90IHN1ZmZpY2llbnQgZm9yIGFuIGltcGxlbWVudGVyLCBp dCBzaG91bGQgcmVseSBvbiB0aGUgZGV0YWlsZWQgc3BlYy4gDQoNCj4gDQo+IC0gUHJldmlvdXMg cmV2aWV3IHN1Z2dlc3RlZCB0aGUgbWFpbiBlZGl0cyByZXF1aXJlZCBzd2l0Y2hpbmcgdGhlDQo+ IHRvcC1sZXZlbA0KPiAgIGNvbnRhaW5lciAnZG90cy1zaWduYWwnLiAgVGhpcyBoYXMgbm93IGJl ZW4gZnVsZmlsbGVkIGJ5IHRoYXQgb2YNCj4gYW4NCj4gICBzeDpzdHJ1Y3R1cmUgaW4gdGhpcyBy ZXZpc2lvbi4NCj4gDQoNCltNZWRdIFRoYW5rcy4gDQoNCj4gLSBBIHJlY2VudCBkaXNjdXNzaW9u IGFtb25nIFlBTkcgZG9jdG9ycyBzdWdnZXN0cyB0aGUgdXNlIG9mDQo+IG5vcm1hdGl2ZQ0KPiAg IGxhbmd1YWdlIChSRkMyMTE5KSBpbiBZQU5HIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMuIEZvciBl eGFtcGxlDQo+ICdzaG91bGQnID0+DQo+ICAgJ1NIT1VMRCcsICdtdXN0JyA9PiAnTVVTVCcsIGV0 Yy4uLiBBIGJlbmVmaXQgdG8gdGhpcyBhcHByb2FjaCBpcw0KPiBSRkMNCj4gICBjb21wcmVoZW5z aW9uIGV2ZW4gd2hlbiB0aGUgbW9kdWxlIGlzIHN0cmlwcGVkIGZyb20gdGhlIHNvdXJjZQ0KPiBk b2N1bWVudCBpdA0KPiAgIGlzIGNvbnRhaW5lZCB1bmRlci4NCg0KW01lZF0gVGhhbmsgeW91IGZv ciBzaGFyaW5nIHRoaXMuIEkgdW5kZXJzdGFuZCB0aGUgYmVuZWZpdCBmb3IgdGhlICJjbGFzc2lj IiB1c2Ugb2YgWUFORywgYnV0IGluIG91ciBjYXNlIEknbSBhZnJhaWQgdGh1cyB0aGlzIHdpbGwg YmUgcmVkdW5kYW50IHdpdGggdGhlIGNvcmUgc3BlY2lmaWNhdGlvbiBpdHNlbGYuIA0KDQo+IA0K PiAtIChkcmFmdCkgTDg4NyBuaXQ6ICJBcyBhIHJlbWluZGVyLCB0aGUgcHJlZml4IGxlbmd0aCBt dXN0IGJlIGxlc3MNCj4gdGhhbiBvcg0KPiAgIGVxdWFsIHRvIDMyIChmb3IgSVB2NCkgZm9yIDEy OCAoZm9yIElQdjYpIg0KDQpbTWVkXSBGaXhlZC4gQ2hhbmdlZCB0bzoNCg0KIkFzIGEgcmVtaW5k ZXIsIHRoZSBwcmVmaXggbGVuZ3RoIG11c3QgYmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDMyIGZv ciBJUHY0IGFuZCAxMjggZm9yIElQdjYuIg0KDQo+IA0KPiBNb2R1bGUgaWV0Zi1kb3RzLXNpZ25h bC1jaGFubmVsOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IC0gSU1PLCB0aGUgbW9kdWxlIHByZWZpeCAnc2lnbmFsJyBpcyB0b28gZ2VuZXJpYyBmb3Igd2hh dCBpcw0KPiBzcGVjaWZpYyB0bw0KPiAgIG1lc3NhZ2UgcGF5bG9hZCBvdmVyIGEgcHJvdG9jb2wg dGhhdCB1c2VzIENvQVAuICBMb29raW5nIGF0IGFsbA0KPiB0aGUNCj4gICBwdWJsaXNoZWQgUkZD cyBmb3IgZG90cywgd2UgaGF2ZSB0aGUgc2FtZSB1c2Ugb2YgZ2VuZXJpYyBwcmVmaXhlcy4NCj4g U2luY2UNCj4gICB0aGUgcHJlZml4IGlzIG9mIGxvY2FsIHNjb3BlLCBpdCBpcyBub3QgYW4gZW50 aXJlbHkgbGFyZ2UgaXNzdWUNCj4gYnV0IGluDQo+ICAgaGluZHNpZ2h0IHNob3VsZCBoYXZlIGhh ZCBzb21lIGJldHRlciBjb25zaXN0ZW5jeSBlc3BlY2lhbGx5IHdoZW4NCj4gdGhlDQo+ICAgcmVj b21tZW5kYXRpb24gdG8gbW9kdWxlIGltcG9ydGVycyBpcyB0byB1dGlsaXplIHRoZSBkZWZpbmVk DQo+IHByZWZpeCBvZiBzYWlkDQo+ICAgbW9kdWxlLg0KDQpbTWVkXSBGYWlyIGVub3VnaC4gQ2hh bmdlZCB0byAiaWV0Zi1kb3RzLXNpZ25hbCIuDQoNCj4gDQo+IC0gVGhpcyBtb2R1bGUgaW1wb3J0 cyBhbmQgcmVmZXJlbmNlcyAnaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbCcgYXMNCj4gcHJlZml4DQo+ ICAgJ2lldGYtZGF0YScuICBOb3Qgb25seSBpcyB0aGlzIHRvbyBnZW5lcmljIGFzIEkgbWVudGlv bmVkIGFib3ZlLA0KPiBpdCBpcyBub3QNCj4gICB1c2luZyB0aGUgc3VnZ2VzdGVkIHByZWZpeCBv ZiAnZGF0YS1jaGFubmVsJyAod2hpY2ggaXMgYWxzbyB0b28NCj4gZ2VuZXJpYykgYXMNCj4gICBk ZWZpbmVkIHdpdGhpbiB0aGF0IG1vZHVsZSAoUkZDNzk1MCBTZWN0aW9uIDcuMS40KQ0KPiANCj4g ICAgIldoZW4gdXNlZCBpbnNpZGUgdGhlICJtb2R1bGUiIHN0YXRlbWVudCwgdGhlICJwcmVmaXgi IHN0YXRlbWVudA0KPiAgICAgZGVmaW5lcyB0aGUgcHJlZml4IHN1Z2dlc3RlZCB0byBiZSB1c2Vk IHdoZW4gdGhpcyBtb2R1bGUgaXMNCj4gaW1wb3J0ZWQuIg0KDQpbTWVkXSBGaXhlZC4gVXBkYXRl ZCB0byB1c2UgJ2RhdGEtY2hhbm5lbCcuDQoNCj4gDQo+IC0gTWlub3Igbml0OiBJdCBhcHBlYXJz IGFsbCBhdXRob3IgZW1haWwgYWRkcmVzc2VzIGhhdmUgYmVlbiB1cGRhdGVkDQo+IHNpbmNlIHRo ZQ0KPiAgIFJGQzg3ODIgdmFyaWFudCByZXBsYWNpbmcgJ0AnIHdpdGggJyYnDQoNCltNZWRdIEZp eGVkLiANCg0KPiANCj4gTW9kdWxlIGlhbmEtZG90cy1zaWduYWwtY2hhbm5lbDoNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtIFNpbWlsYXIgdG8gd2hhdCBJ IG1lbnRpb24gYWJvdmUgcmVnYXJkaW5nIHRoZSBtb2R1bGUgcHJlZml4LCB3ZQ0KPiB1c2UgYQ0K PiAgIGdlbmVyaWMgJ2lhbmEtc2lnbmFsJyBwcmVmaXggaGVyZSB3aGljaCBpcyBpbmNvbnNpc3Rl bnQgYW5kIG5vdA0KPiBkZXNjcmlwdGl2ZQ0KPiAgIG9mIHRoZSBvdmVyYWxsIGludGVudCBvZiB0 aGUgbW9kdWxlLg0KDQpbTWVkXSBVcGRhdGVkIHRvICJpYW5hLXNpZ25hbC1jaGFubmVsIi4NCg0K PiANCj4gT3ZlcmFsbCwgSSdtIG5vdCBzdXJlIGlmIHRoZSBvdGhlciByZWZlcmVuY2VkIGFuZCBw dWJsaXNoZWQgRE9UUw0KPiBZQU5HIG1vZHVsZXMgd2VudCB0aHJvdWdoIGEgWUQgcmV2aWV3IGJ1 dCB0aGUgY29tbWVudHMgYWJvdmUgcmVhbGx5DQo+IHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gYSBu ZXcgcmV2aXNpb24gb2YgdGhvc2UgbW9kdWxlcy4NCg0KW01lZF0gU3VyZS4gV2Ugd2lsbCBkb3Vi bGUgY2hlY2sgdGhvc2UuIA0KDQogIE9uY2UgdGhlDQo+IGFib3ZlIGlzIGFkZHJlc3NlZCBhbmQg cG9zc2libHkgc29tZSBkaXNjdXNzaW9uIGFyb3VuZCB3aGVuIHR5cGUNCj4gcmVzdHJpY3Rpb25z IGFyZSBub3QgY29udmV5ZWQgd2l0aGluIHRoZSBtb2RlbCwgaXQgaXMgcHJvYmFibHkgb24NCj4g dGhlIHJpZ2h0IHRyYWNrLiANCg0KW01lZF0gR3JlYXQsIHRoYW5rcy4gV2UgY2FuIGFkZCBzb21l IGNsYXJpZmljYXRpb24gYXMgbmVlZGVkLCBidXQgYXMgaW5kaWNhdGVkIGFib3ZlLCBpZiB5b3Ug Y2FuIHNoYXJlIHRoZSBhdHRyaWJ1dGVzIHlvdSBhcmUgcmVmZXJyaW5nIHRvLCB0aGlzIHdpbGwg YmUgaGVscGZ1bC4gVGhhbmtzLiAgDQoNCiBTaW5jZSB0aGlzIGlzIG5vdCB0aGUgdXN1YWwgdXNl IG9mIFlBTkcgaW4gdGhlDQo+IGNvbnRleHQgb2YgWUQgcmV2aWV3cywgaXQgaXMgYSBiaXQgb2Yg YW4gb24gdGhlIGZseSBhbmFseXNpcyB3aGljaA0KPiBtYXkgcmVxdWlyZSBzb21lIGFkZGl0aW9u YWwgZGlzY3Vzc2lvbiBhbW9uZyBvdGhlciBZQU5HIGRvY3RvcnMuDQo+IA0KDQpbTWVkXSBTdXJl Lg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Thu Sep 24 17:52:58 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E414A3A048D; Thu, 24 Sep 2020 17:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=nokia.onmicrosoft.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 0_rKVPT432he; Thu, 24 Sep 2020 17:52:55 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2104.outbound.protection.outlook.com [40.107.220.104]) (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 D3D5D3A03F5; Thu, 24 Sep 2020 17:52:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XYOqhV1V6Q+smBywJrd45RlSpWrEw+eoWZcl0WyMuWpKIRlcKPD/GiYXUrfGKdyGQ8Pc4zNazlT1kxaVkyADQ6GDrcSVgxvXKUE2vGyXAPT+gbdi7SSTzVxlKChnr1/EBCBramCKkUI0xB/vO5UJ+ALMuGUsyvHi57zog1RXpv5hso3QDuVDHpYUJ1BLWuHex0A3t3SEPI4VZ62Hcp5zaeCliM962HdoSzDR+Z8Q7CgEFN7KGkIsMRMWdvobmN3CWzjzX/3sQ2zQtJIfgC92GB3F3n4WDAxnHHBdhS2SVBwoBmOPnRCH1ZpKxiZNr66T172Tag5fyXFd+ry2ERLfMA== 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=zTkUQXHL5R7N2EqFV5qT1Y0fLjZfzbMHG0Y8PgrtQmM=; b=Doj+sygnI51eJ6L7FqsLWyXJOuG9RC3cKSFjIfV8gIOWsyEcXo5DWa9Qchfuy3IXPlGNLx5Al3bTuZpwJuBW0Lk86ZhHLsiGb2O8tadJgCgLv0eZ6tjD9H6iZguITeIFuQ55FElDaXTWyVUGziJFxPtDo/9184DF7Cjt1XWDBG8WHWYVtvmOA+UaaYiUlXPK5wzx3TujgT6GvsJsT+MMOZlwpYQ5iyHPiUhpf5Cy0FudM01/P/wMHLExJZ3/ecNFMfh05wpIcMLKrMPgjMzQaqCFJf2llBhAKVTBhwbXEWsGjlfRK7ktuk2ZiKpsB3kFOc10SJ8xI44MdT0ycj1nQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zTkUQXHL5R7N2EqFV5qT1Y0fLjZfzbMHG0Y8PgrtQmM=; b=u98CK19LBBO4WzPQyLEjXt2Qe5HXF+QAPsL0Gi+6zD/zRmrC5h8AfuravzMeCOYLCKsY/3UcESVnaGZCghYoI2UA4aF2sESSzofo326SDGws4A6QWEbQmAtEoOwJ8D2vGbSe8XjSgHwSKfZ/PG2asxT3N5wPlq2QiHMdGEm1NTs= Authentication-Results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=nokia.com; Received: from BN8PR08MB6258.namprd08.prod.outlook.com (2603:10b6:408:db::14) by BN8PR08MB6260.namprd08.prod.outlook.com (2603:10b6:408:da::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Fri, 25 Sep 2020 00:52:52 +0000 Received: from BN8PR08MB6258.namprd08.prod.outlook.com ([fe80::292e:c8f:4e0b:a202]) by BN8PR08MB6258.namprd08.prod.outlook.com ([fe80::292e:c8f:4e0b:a202%9]) with mapi id 15.20.3412.022; Fri, 25 Sep 2020 00:52:52 +0000 Date: Thu, 24 Sep 2020 18:53:00 -0600 From: Ebben Aries To: mohamed.boucadair@orange.com Cc: "yang-doctors@ietf.org" , "dots@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" Message-ID: <20200925005300.GA2034@localhost> References: <160091148495.1709.10744527350560713534@ietfa.amsl.com> <18277_1600936569_5F6C5A79_18277_298_1_787AE7BB302AE849A7480A190F8B9330315459EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <18277_1600936569_5F6C5A79_18277_298_1_787AE7BB302AE849A7480A190F8B9330315459EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Originating-IP: [131.228.48.74] X-ClientProxiedBy: CH2PR20CA0004.namprd20.prod.outlook.com (2603:10b6:610:58::14) To BN8PR08MB6258.namprd08.prod.outlook.com (2603:10b6:408:db::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (131.228.48.74) by CH2PR20CA0004.namprd20.prod.outlook.com (2603:10b6:610:58::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Fri, 25 Sep 2020 00:52:51 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d00fe59d-5e6f-482b-b142-08d860ed54ce X-MS-TrafficTypeDiagnostic: BN8PR08MB6260: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QGV9YI32ffGJwvkH7FQZrAJrsW6As6SmM9vckC77oqZAiJr8yg4+NXulwj2CLhuwCLszA+RxUQQDaUrAeXmwAbbWK4rz/NhWoNp8UMpPqguws159mVsUKEWg3ewCHBRARdiiGTHjk+6W4IOLyonLiPt49Y88N/eV1h5XScGQQP1OSa2rHeQhwlcNJFqtAObTawrjW1WP1ClbujPgVbPQBPynebkK3/i2sYd0theEl6/pryCsSb+jxRx9RSiq22xSE5tnd9HOhD4Yylc1ghzxq2QpUUYxfOMmUXn07YzLr3Jj0HzMG0eUqalnh6orrNBSqKAHsFBY89Mp2fB7D0Y3I1aYn4tPd4rMOWjW8cm1N3Wg8bK7RARgl0mX9kaaxjzd X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR08MB6258.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(39860400002)(366004)(136003)(346002)(9576002)(33716001)(5660300002)(44832011)(1076003)(6496006)(956004)(66946007)(316002)(9686003)(66476007)(6666004)(66556008)(33656002)(55016002)(52116002)(83380400001)(16526019)(186003)(478600001)(4326008)(8936002)(54906003)(8676002)(2906002)(26005)(6916009)(86362001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: 0by5nxKUl23Wqusw8o8I2Yg71onzBQa72cEW5Q/yWBM5Pstf+z3m9OtUAnYHnI0cmysgmc0ekCrlPPggNS0tP9CVb7XxrXyroPj9Q8yinAVUHofwHk5po21Fen6HQ92VL7TuEvJVVyS9nsy2dJ2yaehPfKAVtkZkVBp5gWJRR+AMjkYDiEwALhW94nw3gnHiWatJ6bD0zHubZMefaeNlp//JtDwJ6OXtWEuUWzvUCTNjFsthQOW6LBrmr4UgboT89HCGX2h9h/zdYI4h9+LNWYpSNhLB8CobhRKBMUl/7aV+YdmfogCTqcnONpF7VyAiO5fv3Ju2ahiHYcDO3XG1JoDENQrXNqqnDeT8DjWW2QMX/mkuI4I9pHKFDM+FZDbb8HMtTHP+EzZz3MtgP9dEHd5NyhKkW0IuzLgo7nrOvWUx7spJl+HlA3JzXvXyjbHHqkRDueJOwbpSt6fJQ/Pn1xlGGrQQud3ZK2ZEC2CP8JliTEcC0BdEH3Kh/K67efjkaYvb/KGhigVBZ0SwfXkp8Iy74bnsm+UA4xUPy+MA1Z1wPM1kUQXyl0QbNO+GlynUknmp5xmdCJvaR1ZYw2cbFACh9EC+WVXiEwHW/JjtbUJ6Z1h1QdczmGMYA3NCs5G3/UzmHwp0TJre2ut+6auG3Q== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: d00fe59d-5e6f-482b-b142-08d860ed54ce X-MS-Exchange-CrossTenant-AuthSource: BN8PR08MB6258.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2020 00:52:52.2847 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /CJg7f+eWSuFVNAR7o9MjyJXO8e9EvJmKxZ0sKEiua8lXy9f2fNgpbRcT/L4WS/Jk/hx6cVlL8WhJo0ing2LBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR08MB6260 Archived-At: Subject: Re: [Dots] Yangdoctors early review of draft-ietf-dots-rfc8782-bis-00 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, 25 Sep 2020 00:52:57 -0000 On Sep 24 08:36 AM, mohamed.boucadair@orange.com wrote: > Hi Ebben, all, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Ebben Aries via Datatracker [mailto:noreply@ietf.org] > > Envoyé : jeudi 24 septembre 2020 03:38 > > À : yang-doctors@ietf.org > > Cc : dots@ietf.org; draft-ietf-dots-rfc8782-bis.all@ietf.org > > Objet : Yangdoctors early review of draft-ietf-dots-rfc8782-bis-00 > > > > Reviewer: Ebben Aries > > Review result: On the Right Track > > > > 2 modules in this draft: > > - ietf-dots-signal-channel@2020-07-02.yang > > - iana-dots-signal-channel@2020-05-28.yang > > > > YANG compiler errors or warnings (pyang 2.3.2, yanglint 1.9.2) > > - No compiler errors or warnings however pyang 2.3.2 is currently > > the only > > compiler verified to emit YANG sx:structure data in tree format. > > Instance > > [Med] I confirm this is what we are using. > > > data could not yet easily be validated given the current > > linters/compilers. > > > > General comments on the draft/modules: > > ---------------------------------------- > > The modules defined in this draft are an update replacement to those > > defined in RFC8782 with only 1 being updated from the prior > > publication. > > - ietf-dots-signal-channel@2020-05-28.yang (updated) > > - iana-dots-signal-channel@2020-05-28.yang > > > > - First, I share some of the same comments as the previous review in > > that it > > takes some additional thought on modeling structures for alternate > > protocol > > communications with the YANG language. Overall, I think this is > > likely fine > > but also question where the draft/RFC specification outlines rules > > that are > > not conveyed within the data-model. Some examples include > > specifying > > mandatory attributes but not making use of the YANG 'mandatory' > > statement. > > [Med] We are using "mandatory" statements when this makes sense (e.g., > alt-server, hb-status). It is not used for some attributes that may > appear in both directions, but are not mandatory in one direction. For > example, "lifetime" is mandatory in a mitigation request, but it is > when the server replies with a conflict message. > > FWIW, a constraint we had is to reuse as much as possible the same > CBOR key/attribute names. This is not possible if we overload the > module with "choice"s: > > == > Each "case" may > contain multiple nodes, but each node may appear in only one "case" > under a "choice". > == > > This is why what is normative for an implementation is the core of the > specification not the YANG module itself. > Ack - however just like other verbiage put within the YANG description statements to indicate valid/invalid values (some of which is a direct copy from the document detail), I might expect at a bare minimum the description for the node carry when a node is mandatory within the payload or not if it cannot be expressed via a language statement as you indicate - e.g. This node is mandatory for request and info retrieval operations. Also keep in mind, YD reviews likely have not dealt with many such cases yet so a best practice for these types of use-cases does not necessarily exist yet. > > Other cases are stating the intent of reserved or invalid integers > > but not > > putting the same restrictions on the types under a given data > > node. > > [Med] Can you please indicate which data node are you referring to? Thanks. > A common example to point out... An unbounded int32 with the description yielding the rules around valid values. From a pure type perspective, all values that fall within the int32 range are valid and data validation is only then left to the running implementation and conveying invalid boundaries by way of protocol error messaging. 105 leaf lifetime { 106 type int32; 107 units "seconds"; 108 default "3600"; 109 description 110 "Indicates the lifetime of the mitigation request. 111 112 A lifetime of '0' in a mitigation request is an 113 invalid value. 114 115 A lifetime of negative one (-1) indicates indefinite 116 lifetime for the mitigation request."; 117 } Now to be fair, this also exists in datastore related modules where the instance data can be valid from a data-model conformance standpoint but still not meet the requirements of the implementation - all such cases make it harder for the model consumer to fully validate instance data outside of the complete implementation. The tradeoff of leaving this outside the schema is likely fine here. > Overall > > this means that you cannot validate the instance/payload data > > according to > > the data-model alone. > > [Med] Agree. The data model alone is not sufficient for an > implementer, it should rely on the detailed spec. > > > > > - Previous review suggested the main edits required switching the > > top-level > > container 'dots-signal'. This has now been fulfilled by that of > > an > > sx:structure in this revision. > > > > [Med] Thanks. > > > - A recent discussion among YANG doctors suggests the use of > > normative > > language (RFC2119) in YANG description statements. For example > > 'should' => > > 'SHOULD', 'must' => 'MUST', etc... A benefit to this approach is > > RFC > > comprehension even when the module is stripped from the source > > document it > > is contained under. > > [Med] Thank you for sharing this. I understand the benefit for the > "classic" use of YANG, but in our case I'm afraid thus this will be > redundant with the core specification itself. > YANG modules can become detached from the IETF document containing them (and is the intention for the normal uses as you mention) and for this purpose, the module should be as descriptive as possible to live on its own. Now for this use, you are defining solely message structures which can likely still be used for library code generation on its own without further context. The implementation however will need to take into account the specification to build upon and this is fine. And yes, for all other cases I mention the intention is to be redundant carrying the verbiage from the specification detail into the YANG description statements for consistency - especially here where a protocol specification will already carry this in the detail. > > > > - (draft) L887 nit: "As a reminder, the prefix length must be less > > than or > > equal to 32 (for IPv4) for 128 (for IPv6)" > > [Med] Fixed. Changed to: > > "As a reminder, the prefix length must be less than or equal to 32 for IPv4 and 128 for IPv6." > > > > > Module ietf-dots-signal-channel: > > ---------------------------------------- > > - IMO, the module prefix 'signal' is too generic for what is > > specific to > > message payload over a protocol that uses CoAP. Looking at all > > the > > published RFCs for dots, we have the same use of generic prefixes. > > Since > > the prefix is of local scope, it is not an entirely large issue > > but in > > hindsight should have had some better consistency especially when > > the > > recommendation to module importers is to utilize the defined > > prefix of said > > module. > > [Med] Fair enough. Changed to "ietf-dots-signal". > > > > > - This module imports and references 'ietf-dots-data-channel' as > > prefix > > 'ietf-data'. Not only is this too generic as I mentioned above, > > it is not > > using the suggested prefix of 'data-channel' (which is also too > > generic) as > > defined within that module (RFC7950 Section 7.1.4) > > > > "When used inside the "module" statement, the "prefix" statement > > defines the prefix suggested to be used when this module is > > imported." > > [Med] Fixed. Updated to use 'data-channel'. > > > > > - Minor nit: It appears all author email addresses have been updated > > since the > > RFC8782 variant replacing '@' with '&' > > [Med] Fixed. > > > > > Module iana-dots-signal-channel: > > ---------------------------------------- > > - Similar to what I mention above regarding the module prefix, we > > use a > > generic 'iana-signal' prefix here which is inconsistent and not > > descriptive > > of the overall intent of the module. > > [Med] Updated to "iana-signal-channel". > > > > > Overall, I'm not sure if the other referenced and published DOTS > > YANG modules went through a YD review but the comments above really > > should be addressed in a new revision of those modules. > > [Med] Sure. We will double check those. > > Once the > > above is addressed and possibly some discussion around when type > > restrictions are not conveyed within the model, it is probably on > > the right track. > > [Med] Great, thanks. We can add some clarification as needed, but as > indicated above, if you can share the attributes you are referring to, > this will be helpful. Thanks. > > Since this is not the usual use of YANG in the > > context of YD reviews, it is a bit of an on the fly analysis which > > may require some additional discussion among other YANG doctors. > > > > [Med] Sure. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Fri Sep 25 04:20:07 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC113A1373; Fri, 25 Sep 2020 04:20:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160103280125.32446.4340535702473570714@ietfa.amsl.com> Date: Fri, 25 Sep 2020 04:20:01 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-rfc8782-bis-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, 25 Sep 2020 11:20: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 : Mohamed Boucadair Jon Shallow Tirumaleswar Reddy.K Filename : draft-ietf-dots-rfc8782-bis-01.txt Pages : 120 Date : 2020-09-25 Abstract: This document specifies the Distributed Denial-of-Service Open Threat Signaling (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. This document obsoletes RFC 8782. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-01 https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-rfc8782-bis-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 Sep 25 04:26:27 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622A03A1379; Fri, 25 Sep 2020 04:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9Z_4zdVIdxio; Fri, 25 Sep 2020 04:26:22 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8533A1376; Fri, 25 Sep 2020 04:26:22 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4ByV3c50HtzCrrH; Fri, 25 Sep 2020 13:26:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601033180; bh=T7Vqkaq8t2JIulAX/PY3XHnn9HACYmoqCi5wE2kV/t4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bIlZXG+Bnp7bgqfXIj8mnCwOBHQFQEBLrPVTnKN+WeY8J6F29nxuVOAZu4MndhuoV 4HvR1fvfKbfE9w2Q+/8GFJ4csWdq1NY1ml9s6JldJYOzLJO6YS9jV7VlbTtV+ScAyd wgWBGnwNJvkquDzW+7V1dStbZZHNV9R6V9ECzYi9oQESFRTuDt3zwQ8BxBCoRO2rzB q/VHNMhPO+N5bj8WaaWterpiFpDTplPwNomZNL4+ItgejpdF/bmr7ZTvnO0pY7HLfo YEx1B1obHoli7u2/P3U7VvLo5TQ6UpMgu75+H7QgAvK/TF+255uDYEHrstuCMB8scV NcFhVTORN8E5Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4ByV3c3rfBzyQ4; Fri, 25 Sep 2020 13:26:20 +0200 (CEST) From: To: Ebben Aries CC: "yang-doctors@ietf.org" , "dots@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-dots-rfc8782-bis-00 Thread-Index: AQHWktY16QJgyyUzE0aP4KpAgGJvfql5NgTw Date: Fri, 25 Sep 2020 11:26:20 +0000 Message-ID: <6563_1601033180_5F6DD3DC_6563_9_1_787AE7BB302AE849A7480A190F8B933031546980@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160091148495.1709.10744527350560713534@ietfa.amsl.com> <18277_1600936569_5F6C5A79_18277_298_1_787AE7BB302AE849A7480A190F8B9330315459EC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200925005300.GA2034@localhost> In-Reply-To: <20200925005300.GA2034@localhost> 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] Yangdoctors early review of draft-ietf-dots-rfc8782-bis-00 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, 25 Sep 2020 11:26:24 -0000 Hi Ebben,=20 Thank you. An udpated verison that takes into account your review is availa= ble at:=20 https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-01=20 https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-01=20 A diff from the previous version is available at: https://github.com/boucadair/rfc8782-yang-update/blob/master/Ebben-Review.p= df=20 Cheers, Med > -----Message d'origine----- > De=A0: Ebben Aries [mailto:ebben.aries@nokia.com] > Envoy=E9=A0: vendredi 25 septembre 2020 02:53 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: yang-doctors@ietf.org; dots@ietf.org; draft-ietf-dots-rfc8782- > bis.all@ietf.org > Objet=A0: Re: Yangdoctors early review of draft-ietf-dots-rfc8782-bis- > 00 >=20 > On Sep 24 08:36 AM, mohamed.boucadair@orange.com wrote: > > Hi Ebben, all, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Ebben Aries via Datatracker [mailto:noreply@ietf.org] > Envoy=E9=A0: > > > jeudi 24 septembre 2020 03:38 =C0=A0: yang-doctors@ietf.org Cc=A0: > > > dots@ietf.org; draft-ietf-dots-rfc8782-bis.all@ietf.org > > > Objet=A0: Yangdoctors early review of draft-ietf-dots-rfc8782-bis- > 00 > > > > > > Reviewer: Ebben Aries > > > Review result: On the Right Track > > > > > > 2 modules in this draft: > > > - ietf-dots-signal-channel@2020-07-02.yang > > > - iana-dots-signal-channel@2020-05-28.yang > > > > > > YANG compiler errors or warnings (pyang 2.3.2, yanglint 1.9.2) > > > - No compiler errors or warnings however pyang 2.3.2 is > currently > > > the only > > > compiler verified to emit YANG sx:structure data in tree > format. > > > Instance > > > > [Med] I confirm this is what we are using. > > > > > data could not yet easily be validated given the current > > > linters/compilers. > > > > > > General comments on the draft/modules: > > > ---------------------------------------- > > > The modules defined in this draft are an update replacement to > those > > > defined in RFC8782 with only 1 being updated from the prior > > > publication. > > > - ietf-dots-signal-channel@2020-05-28.yang (updated) > > > - iana-dots-signal-channel@2020-05-28.yang > > > > > > - First, I share some of the same comments as the previous > review in > > > that it > > > takes some additional thought on modeling structures for > alternate > > > protocol > > > communications with the YANG language. Overall, I think this > is > > > likely fine > > > but also question where the draft/RFC specification outlines > rules > > > that are > > > not conveyed within the data-model. Some examples include > > > specifying > > > mandatory attributes but not making use of the YANG > 'mandatory' > > > statement. > > > > [Med] We are using "mandatory" statements when this makes sense > (e.g., > > alt-server, hb-status). It is not used for some attributes that > may > > appear in both directions, but are not mandatory in one direction. > For > > example, "lifetime" is mandatory in a mitigation request, but it > is > > when the server replies with a conflict message. > > > > FWIW, a constraint we had is to reuse as much as possible the same > > CBOR key/attribute names. This is not possible if we overload the > > module with "choice"s: > > > > =3D=3D > > Each "case" may > > contain multiple nodes, but each node may appear in only one > "case" > > under a "choice". > > =3D=3D > > > > This is why what is normative for an implementation is the core of > the > > specification not the YANG module itself. > > >=20 > Ack - however just like other verbiage put within the YANG > description statements to indicate valid/invalid values (some of > which is a direct copy from the document detail), I might expect at > a bare minimum the description for the node carry when a node is > mandatory within the payload or not if it cannot be expressed via a > language statement as you indicate - e.g. This node is mandatory for > request and info retrieval operations. >=20 > Also keep in mind, YD reviews likely have not dealt with many such > cases yet so a best practice for these types of use-cases does not > necessarily exist yet. >=20 > > > Other cases are stating the intent of reserved or invalid > integers > > > but not > > > putting the same restrictions on the types under a given data > > > node. > > > > [Med] Can you please indicate which data node are you referring > to? Thanks. > > >=20 > A common example to point out... >=20 > An unbounded int32 with the description yielding the rules around > valid values. From a pure type perspective, all values that fall > within the > int32 range are valid and data validation is only then left to the > running implementation and conveying invalid boundaries by way of > protocol error messaging. >=20 > 105 leaf lifetime { > 106 type int32; > 107 units "seconds"; > 108 default "3600"; > 109 description > 110 "Indicates the lifetime of the mitigation request. > 111 > 112 A lifetime of '0' in a mitigation request is an > 113 invalid value. > 114 > 115 A lifetime of negative one (-1) indicates indefinite > 116 lifetime for the mitigation request."; > 117 } >=20 > Now to be fair, this also exists in datastore related modules where > the instance data can be valid from a data-model conformance > standpoint but still not meet the requirements of the implementation > - all such cases make it harder for the model consumer to fully > validate instance data outside of the complete implementation. >=20 > The tradeoff of leaving this outside the schema is likely fine here. >=20 > > Overall > > > this means that you cannot validate the instance/payload data > > > according to > > > the data-model alone. > > > > [Med] Agree. The data model alone is not sufficient for an > > implementer, it should rely on the detailed spec. > > > > > > > > - Previous review suggested the main edits required switching > the > > > top-level > > > container 'dots-signal'. This has now been fulfilled by that > of > > > an > > > sx:structure in this revision. > > > > > > > [Med] Thanks. > > > > > - A recent discussion among YANG doctors suggests the use of > > > normative > > > language (RFC2119) in YANG description statements. For example > > > 'should' =3D> > > > 'SHOULD', 'must' =3D> 'MUST', etc... A benefit to this approach > is > > > RFC > > > comprehension even when the module is stripped from the source > > > document it > > > is contained under. > > > > [Med] Thank you for sharing this. I understand the benefit for the > > "classic" use of YANG, but in our case I'm afraid thus this will > be > > redundant with the core specification itself. > > >=20 > YANG modules can become detached from the IETF document containing > them (and is the intention for the normal uses as you mention) and > for this purpose, the module should be as descriptive as possible to > live on its own. >=20 > Now for this use, you are defining solely message structures which > can likely still be used for library code generation on its own > without further context. The implementation however will need to > take into account the specification to build upon and this is fine. >=20 > And yes, for all other cases I mention the intention is to be > redundant carrying the verbiage from the specification detail into > the YANG description statements for consistency - especially here > where a protocol specification will already carry this in the > detail. >=20 > > > > > > - (draft) L887 nit: "As a reminder, the prefix length must be > less > > > than or > > > equal to 32 (for IPv4) for 128 (for IPv6)" > > > > [Med] Fixed. Changed to: > > > > "As a reminder, the prefix length must be less than or equal to 32 > for IPv4 and 128 for IPv6." ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sun Sep 27 12:48: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 38A623A0ADD; Sun, 27 Sep 2020 12:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvLH3c30cz-2; Sun, 27 Sep 2020 12:48:46 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782663A011B; Sun, 27 Sep 2020 12:48:46 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08RJmf5Z008867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 27 Sep 2020 15:48:44 -0400 Date: Sun, 27 Sep 2020 12:48:41 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "draft-ietf-dots-server-discovery.all@ietf.org" , "dots@ietf.org" Message-ID: <20200927194841.GD89563@kduck.mit.edu> References: <20200918202211.GI89563@kduck.mit.edu> <17479_1600698186_5F68B74A_17479_404_1_787AE7BB302AE849A7480A190F8B933031543746@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17479_1600698186_5F68B74A_17479_404_1_787AE7BB302AE849A7480A190F8B933031543746@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-server-discovery-10 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:48:49 -0000 Hi Med, Thanks for the responses (and the follow-up link to the staged changes). Just covering the remaining topics inline; this generally looks good. On Mon, Sep 21, 2020 at 02:23:05PM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Thank for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : vendredi 18 septembre 2020 22:22 > > À : draft-ietf-dots-server-discovery.all@ietf.org > > Cc : dots@ietf.org > > Objet : AD review of draft-ietf-dots-server-discovery-10 > > > > Hi all, > > > > Despite the first half of the review basically being entirely nits, > > there are some substantive comments in there later on. (Would it be > > helpful if I tried harder to split the nits out into a separate > > section in the future?) > > > > Overall it's pretty straightforward, so no major issues left to > > address; sorry for taking so long to get through it. > > > > > > One thing that we should definitely fix before getting more eyes on > > this document is that both TBD1 and TBD2 are overloaded -- we use > > them to refer to the port assignments from the signal channel and > > call home protocol assignments, but also for the DHCPv6 option > > codes. > > [Med] We used TBA1/TBA2 in the core text for the codes to be assigned for DHCPv6. Fixed the IANA section, though. > [...] > > > > All DOTS clients MUST support at least one of the three > > mechanisms > > below to determine a DOTS server list. All DOTS clients SHOULD > > implement all three, or as many as are practical for any specific > > device (e.g., a CPE will support the first two mechanisms, a host > > within a LAN will support the last two mechanisms, or an > > application > > server will support a local configuration. More samples are > > discussed in Section 3), of these ways to discover DOTS servers, > > in > > order to facilitate the deployment of DOTS in large scale > > environments: > > > > nit: the way the parenthetical is structured is a bit unusual, with > > a sentence break occurring within the parentheses (and leaving quite > > a gap for processing in the middle of the thought "implement all > > three of these ways"). It's probably okay to just make the "SHOULD > > implement all three" a single standalone sentence, and leave the > > clarification of when implementing all three is > > infeasible/unnecessary to a follow-up sentence. > > [Med] Will split to ease the readability. Thanks, it looks a lot better. [...] > > > > Let's consider that the DOTS server is reachable at > > 2001:db8:122:300::1 while the Call Home DOTS client is > > reachable > > at 2001:db8:122:300::2. The DHCP server will then return one > > DOTS > > reference identifier and a list that includes both > > 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting > > DHCP > > client. That list is passed to the DOTS client (or Call Home > > DOTS > > server) which will try to establish connections to the > > addresses > > of that list and destination port number TBD1 (or TBD2). As a > > result, the DOTS client (or Call Home DOTS server) will select > > 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server > > (or > > Call Home DOTS client). > > > > I mostly expect pushback from TSV-area reviewers about giving the > > allocated port numbers such importance in selecting the peer address > > to use. > > [Med] We need to demux call-home from the base signal channel. We have text in the call home draft to explain this. We can point the reviewers to that section. Okay, we can see if that is persuasive enough to convince the reviewers. > > > > Section 5.1.2 > > > > format of this option is shown in Figure 5. As a reminder, this > > format follows the guidelines for creating new DHCPv6 options > > (Section 5.1 of [RFC7227]). > > > > We need the reminder for the second option but not the first one? ;) > > [Med] Because we don't have a section to cite. There is only a list discussed in 5.10 but we don't only need one name. > > > > > Section 5.1.3 > > > > are used to reach the peer DOTS agent. In other words, the name > > conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying > > resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a > > response. > > > > I'm not sure how much of this needs to end up in the document > > itself, but can we walk through the scenarios here, especially when > > the DNS-resolution addresses for the name in question differ from > > the addresses in OPTION_V6_DOTS_ADDRESS? > > [Med] Actually, we want to avoid the aliasing issues discussed in RFC7227#section-7 (the resolution may lead to different addresses if the logic for binding a client to server is not visible to "public" resolvers). > > When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence. The client must not try to resolve the OPTION_V6_DOTS_RI. Thanks for the reference+discussion. (I might say that we still have the aliasing, but we try to forestall the negative consequences by defining a specific priority order of processing.) > I don't understand yet > > why/how this scheme ends up being safe, and am hoping that you have > > a head start over me on doing the analysis :) > > [Med] Returning both the address and the RI in the DHCP prevents redirecting a client to a "fake" server if the DNS queries are intercepted. We don't have this issue if both the address and the RI are returned in DHCP. I think my main concern here is that we get back a name to use for authenticating the resulting connection, but then are told to not use our normal procedure for establishing a secure connection to a named entity. In theory the PKI structure should protect the communication no matter how we decide to establish the connection (we trust the CA and the name is certified by the trusted CA chain), but this kind of short-circuiting can make some classes of attack easier -- if an attacker can get a fraudulently issued cert, this mechanism lets them send the victim directly to the attacker's machine without needing to also adjust the DNS/resolution path on the victim. Your example of a split-DNS case seems apt, but we should probably mention the loss of "defense in depth" against mis-issued certificates in the security considerations. Which risk is more concerning (DNS spoofing vs. mis-issued cert) will probably depend on the deployment specifics, including DNSSEC (non)usage, so we will probably just have to document the tradeoff. > > > > If the DHCP client receives OPTION_V6_DOTS_RI only, but > > OPTION_V6_DOTS_RI option contains more than one name, as > > > > nit: insert "the" at the start of the second line. > > [Med] deleted "option". > > > > > If the DHCP client receives OPTION_V6_DOTS_RI only, but > > OPTION_V6_DOTS_RI option contains more than one name, as > > distinguished by the presence of multiple root labels, the DHCP > > client MUST use only the first name. Once the name is validated > > > > Is there a reason to make this "use the first one" vs. "ignore the > > whole thing as malformed? > > [Med] If the message is ignored, the service won't be provided. > > > > > (Section 8 of [RFC8415]), the name is passed to a name resolution > > library. Moreover, that name is also used as a reference > > identifier > > for authentication purposes. > > > > Hmm, I'm not seeing much in Section 8 specifically of RFC 8415 that > > looks relevant here. Was perhaps a different document intended? > > [Med] It used to be "Section 8 of 3315", but since 3315 was obsoleted by 8415, it should read "Section 10 of 8415". Good catch. Thanks. > > > > > Section 5.2.1 > > > > A reference to 2132 here would be timely, not least for > > understanding the figure. > > > > [Med] OK. > > > The values s1, s2, s3, etc. represent the domain name labels in > > the > > domain name encoding. > > > > super-nitty-nit: maybe "the octets of the domain name labels"? IIUC > > the RFC 2132 convention is to give such names to the individual > > bytes of the DHCP option, but this wording implies that we are > > naming labels, which are multi-byte (except for the root). > > [Med] I see your point but the figure uses the convention used in many other dhc wg document. I will leave it. Bernie (dhc co-chair) reviewed the dhcp part of the document and he didn't raise a comment about this. Okay, thanks. I only took a narrow view into previous DHCP documents, so he would have a better sense for what is current. > > > > Section 5.2.2 > > > > I wonder if anyone will complain that we are using a more "modern" > > structure for the figure, instead of keeping with the "traditional" > > DHCP option diagrams. > > [Med] At least, Bernie didn't complain when he reviewed the document. > > > > > Section 5.2.3 > > > > To discover a peer DOTS agent, the DHCPv4 client MUST include > > both > > OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter > > Request > > List Option [RFC2132]. > > > > Why is the v4 case a MUST but the v6 case was only MAY? > > [Med] Because we start the v4 text with "To discover a peer DOTS agent,". We could align both, though. > > > > > If the DHCP client receives more than one instance of > > OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use > > only the first instance of that option. > > > > I think the parenthetical needs to be dropped, since in the previous > > section we say that this is a concatenation-requiring option. > > [Med] Agree. > > > > > If the DHCP client receives OPTION_V4_DOTS_RI only, but > > OPTION_V4_DOTS_RI option contains more than one name, as > > distinguished by the presence of multiple root labels, the DHCP > > client MUST use only the first name. Once the name is validated > > (Section 10 of [RFC8415]), the name is passed to a name > > resolution > > library. Moreover, that name is also used as a reference > > identifier > > for authentication purposes. > > > > [same comments about "use first" as for v4] I see that here we > > reference §10, rather than 8, of RFC 8415, though it still doesn't > > say much explicitly about a "validation procedure". > > [Med] The validation is basically check it follows Section 3.1 of [RFC1035] and compression is not used. > > > > > The diff between §5.1.3 and 5.2.3 includes "(e.g., PKIX [RFRC6125])" > > only in 5.1.3; it seems like it would also apply here. > > [Med] Indeed. > > > > > The DHCP client MUST silently discard multicast and host loopback > > addresses conveyed in OPTION_V4_DOTS_ADDRESS. > > > > Can we put a reference for "multicast and host loopback" addresses > > as we did for the v6 case? > > [Med] Sure. > > > > > Section 6 > > > > 1. A DNS domain name is retrieved for each combination of > > interface > > and address family. A DOTS agent has to determine the domain > > in > > which it is located relying on dynamic means such as DHCP > > (Section 5) . [...] > > > > Hmm, this may be worth a closer look. If I understand correctly, if > > the procedures in Section 5 only give you a name, you're supposed to > > use DNS to get IP addresses to talk to, from that name. So is this > > procedure only applicable when the A/AAAA lookup fails? Otherwise > > I'm not sure how you would get only a name but not full contact > > information, from the section 5 procedure. Or, if the intent of > > "the name is passed to a name resolution library" in Section 5 is to > > induce the S-NAPTR lookups defined here, Section 5 should be more > > clear about that. > > [Med] S-NAPTR lookups is covered by "... to a name resolution library". Nevertheless, some deployments may not require S-NAPTR lookups and A/AAAA resolution would be just fine. > > > > > Once the DOTS agent has retrieved its DNS domain or discovered > > the > > peer DOTS agent name that needs to be resolved (e.g., Section 5), > > an > > > > (The parenthetical seems redundant with step (1).) > > [Med] Fixed. > > > > > S-NAPTR lookup with 'DOTS' application service and the desired > > [...] > > This specification defines "DOTS" and "DOTS-CALL-HOME" as > > application > > service tags (Sections 9.4.1 and 9.4.2). It also defines > > > > We should probably mention "DOTS-CALL-HOME" in both places, or just > > say something generic like "the appropriate application service" in > > the first instance, instead of only saying 'DOTS' the first time. > > > > [Med] Went for "the appropriate application service". > > > a.example.net. > > IN AAAA 2001:db8::1 > > > > I'm sure my INT-area colleagues will appreciate the IPv6 examples :) > > > > Section 8 > > > > Having a clearly defined priority order for using the different > > discovery mechanisms covers most of the potential security > > considerations inherently, but I think some text is in order about > > whether an attacker can block/modify traffic to force a "lower > > priority" > > mechanism to be used (but would not be able to modify the "higher > > priority" mechanism's results with the same capabilities). > > [Med] Good point. I added the folliwng: > > "An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery mechanism with a lower priority. The security implications of such attack are those inherent to the fallback discovery mechanism discussed in the following subsections. " Thanks for adding the mention of forcing a lower priority; I think I'll need to reread the whole thing in context to see if I want to have anything else mentioned here. > > > > We may also want to reiterate that discovery results are scoped by > > interface and address family, and that bad things can happen if you > > use a result from one interface for traffic from a different > > interface. > > [Med] We can add the following: > > "The results of the discovery procedure are a function of the interface/address family. Contacting a discovered DOTS server via an interface to which it is not bind may exacerbate the delay required to establish a DOTS channel. Moreover, such behavior may reveal that a DOTS service is enabled by a DOTS client domain and exposes the identity of the DOTS service provider (that can be inferred from the name and the destination IP address) to external networks." > > > > > There are probably not particularly interesting privacy > > considerations of advertising/exposing DOTS server names in these > > various discovery mechanisms, but a brief section on privacy > > considerations is likely in order regardless. > > [Med] The NEW text above touched on "privacy". I'm not sure what we need to say more. The one I had in mind when writing the above was "if you put the name/address of your DOTS server/call-home-client in DHCP or DNS, people with access to that DNS/DHCP can find out the name/address of your DOTS server/call-home-client", which is both (1) hopefully obvious and (2) may not be particularly sensitive information, though I guess the DOTS server might be an interesting DDOS target itself... > > > > Section 8.2 > > > > The primary attack against the methods described in Section 6 is > > one > > that would lead to impersonation of a peer DOTS agent. An > > attacker > > could attempt to compromise the S-NAPTR resolution. The use of > > mutual authentication makes it difficult to redirect a DOTS > > client > > (or a Call Home DOTS server) to an illegitimate DOTS server (or a > > Call Home DOTS client). > > > > IIUC this property only holds if the domain name used for > > authenticating the peer (i.e., the input to the RFC 6125 procedures) > > is the one used as input to the procedure in Section 6, not the > > intermediate names produced during that procedure (e.g., > > "example.net" as input and "a.example.net" > > as intermediate, from Figure 10). I don't think we specify anywhere > > that this must be the case, so on the face of it it seems that in > > the absence of DNSSEC, an attacker spoofing DNS responses can > > redirect the client to an arbitrary name controlled by the attacker, > > for which the attacker has valid PKIX credentials. (We also allow > > SRV-IDs for validation, so the SRV names are also affected.) I also > > note that the analogous question for mail servers (whether they > > authenticate as example.net or a.example.net) is a recurring source > > of trouble, so our hand may be forced by deployment realities. > > [Med] Good point. Will update the text. Thanks. > > > > Section 8.3 > > > > I was going to say that we should reference the RFC 6763 security > > considerations, too, but they are just saying the same things we > > already say. > > > > Section 12.2 > > > > I expect at least one AD to suggest that the architecture draft > > should be normative since we require it for terminology, but I don't > > insist on changing its classification at this time. (Likewise for > > Call Home.) > > > > [Med] Will let them as they are. Let's see if we will get comments on this. Sounds good. If you could try to add a mention of the "attacker-supplied IP addresses makes it easier to use a mis-issued certificate" case to the security considerations and publish the new version, it sounds like this will be ready for IETF LC. Thanks again, Ben From nobody Sun Sep 27 12:53:40 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FE63A0AF3 for ; Sun, 27 Sep 2020 12:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwy-dND2QNTG for ; Sun, 27 Sep 2020 12:53:37 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8689A3A0141 for ; Sun, 27 Sep 2020 12:53:37 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08RJrX93010035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 27 Sep 2020 15:53:35 -0400 Date: Sun, 27 Sep 2020 12:53:32 -0700 From: Benjamin Kaduk To: Jon Shallow Cc: supjps-ietf-draft-ietf-dots-server-discovery.all@ietf.org, dots@ietf.org Message-ID: <20200927195332.GE89563@kduck.mit.edu> References: <20200918202211.GI89563@kduck.mit.edu> <0e5701d68ffc$c6365b70$52a31250$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e5701d68ffc$c6365b70$52a31250$@jpshallow.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-server-discovery-10 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 19:53:39 -0000 Hi Jon, Thanks for ths implementation insight (I reply to the original message that has the complete list of mechanisms you implemented, presumably in priority order). A few notes inline. On Mon, Sep 21, 2020 at 10:51:27AM +0100, Jon Shallow wrote: > Hi Ben, > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > Benjamin Kaduk > > Sent: 18 September 2020 21:22 > > To: draft-ietf-dots-server-discovery.all@ietf.org > > Cc: dots@ietf.org > > Subject: [Dots] AD review of draft-ietf-dots-server-discovery-10 > > Thanks for this, > > I have implemented this (for both DOTS client r and Call Home DOTS server) > as > IP-Address > Domain > DHCP > S-NAPTR > DNS-SD > And one or more of these can be defined, so providing a search order. > > I will try to address the more technical comments that you raised as some of > these may have been triggered by doing the above work. For the sake of > brevity, I am skipping over the nits which can be addressed by the authors. > > > > > o Expiry of a lease associated with a discovered DOTS agent. > > > > Is this specifically a DHCP lease, or a more generic concept? > > Interesting question - DNS has a TTL - should we be enforcing a refresh here > as well? > - my implementation does not do this at present I see Med added mention of TTL in the staged changes, which helps clue in the reader. I don't know whether we specifically need to mandate a refresh, since that is probably covered by the core DNS specs (not that they are an easy read to digest...) > > Let's consider that the DOTS server is reachable at > > 2001:db8:122:300::1 while the Call Home DOTS client is reachable > > at 2001:db8:122:300::2. The DHCP server will then return one DOTS > > reference identifier and a list that includes both > > 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP > > client. That list is passed to the DOTS client (or Call Home DOTS > > server) which will try to establish connections to the addresses > > of that list and destination port number TBD1 (or TBD2). As a > > result, the DOTS client (or Call Home DOTS server) will select > > 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or > > Call Home DOTS client). > > > > I mostly expect pushback from TSV-area reviewers about giving the > > allocated port numbers such importance in selecting the peer address to > > use. > > We do need a method for differentiation between whether the address is for a > DOTS server or Call Home Dots client. Definitely. They tend to try to push people to use a dynamic port-discovery mechanism and avoid assuming that a registered port is used for the registered use, but I don't have great insight into the specific considerations there, so we may have to wait and see. > > Section 5.1.3 > > > > are used to reach the peer DOTS agent. In other words, the name > > conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying > > resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a > > response. > > > > I'm not sure how much of this needs to end up in the document itself, > > but can we walk through the scenarios here, especially when the > > DNS-resolution addresses for the name in question differ from the > > addresses in OPTION_V6_DOTS_ADDRESS? I don't understand yet why/how > > this scheme ends up being safe, and am hoping that you have a head start > > over me on doing the analysis :) > > I don't immediately recall the rational for this, but if both are returned > there needs to be a preference for one of them and think that > OPTION_V6_DOTS_ADDRESS is the priority. It is conceivable that the > OPTION_V6_DOTS_RI, when resolved, may point to an address that is not in the > local domain (i.e. traffic needs to go via a DOTS gateway rather than direct > to a DOTS server). > > > If the DHCP client receives OPTION_V6_DOTS_RI only, but > > OPTION_V6_DOTS_RI option contains more than one name, as > > distinguished by the presence of multiple root labels, the DHCP > > client MUST use only the first name. Once the name is validated > > > > Is there a reason to make this "use the first one" vs. "ignore the whole > > thing as malformed? > > 5.1.1. implies that that there can only be a singular dots-agent-name, so I > would go for "ignore the whole thing as malformed" (but raise an alert that > there is a misconfiguration). Med noted that rejecting it would prevent receiving the requested service. This is hopefully an exceptional case, so presumably would not matter too much, and is just a tradeoff on strict compliance vs runtime resiliance (roughly speaking, the Postel principle). > > > > Section 5.2.3 > > > > To discover a peer DOTS agent, the DHCPv4 client MUST include both > > OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter > > Request > > List Option [RFC2132]. > > > > Why is the v4 case a MUST but the v6 case was only MAY? > > I think that this was down to NAT being more likely in V4, and so the IP > addresses take preference over the domain name returned. That said, I guess > V6 could be a MUST as well. > > I do recall that I had issues with the DHCP client (Centos) for V4 - where I > could not just ask for these options and get back a sensible response - > there was an inherent assumption that it would normally be used for getting > the DHCP IP/Name etc for the requesting interface, not for just requesting > the information of some remote object. This was not an issue for V6. It > maybe that I had to provide both options for it to work - I need to go back > and test this out at some point. > > > > > Section 6 > > > > 1. A DNS domain name is retrieved for each combination of interface > > and address family. A DOTS agent has to determine the domain in > > which it is located relying on dynamic means such as DHCP > > (Section 5) . [...] > > > > Hmm, this may be worth a closer look. If I understand correctly, if the > > procedures in Section 5 only give you a name, you're supposed to use DNS > > to get IP addresses to talk to, from that name. So is this procedure > > only applicable when the A/AAAA lookup fails? Otherwise I'm not sure > > how you would get only a name but not full contact information, from the > > section 5 procedure. Or, if the intent of "the name is passed to a name > > resolution library" in Section 5 is to induce the S-NAPTR lookups > > defined here, Section 5 should be more clear about that. > > My understanding was that we need to start with a seed domain that needs to > be 'acquired' from somewhere. The standard domain that is allocated to a > device may not be the same domain that handles the DOTS S-NAPTR - hence > OPTION_V(4|6)_DOTS_RI responses can be used to get the DOTS relevant domain. > > > > > a.example.net. > > IN AAAA 2001:db8::1 > > > > I'm sure my INT-area colleagues will appreciate the IPv6 examples :) > > I firmed up on the final version of this after many failing attempts to get > things right and working! Thanks again, Ben From nobody Sun Sep 27 23:45:16 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 0AE5C3A0E8B; Sun, 27 Sep 2020 23:45:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160127550900.9559.1539163603950261518@ietfa.amsl.com> Date: Sun, 27 Sep 2020 23:45:09 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-11.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 06:45:09 -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-11.txt Pages : 25 Date : 2020-09-27 Abstract: This document specifies mechanisms to configure Districuted Denial of Service Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. Knowing the appropriate DOTS server for a given location can be useful to engage mitigation actions even in cases where the DOTS client cannot localize the attack, but only knows that some resources are under attack and that help is needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-server-discovery-11 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 27 23:48:23 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD393A0E91; Sun, 27 Sep 2020 23:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM1gbj9rG-Ma; Sun, 27 Sep 2020 23:48:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D1B3A0E90; Sun, 27 Sep 2020 23:48:21 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4C0ClR2dTmzCrN9; Mon, 28 Sep 2020 08:48:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601275699; bh=JfaMBWry9X/htv5mG8IldHDMPjvnfuR/kqtKgQohOz8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kUU08f9vyAvQVBlEYF7wavJMQxjEt2OVu5M+nhsS2ePe8PWBzpKO9/dt+ejBcWU3/ 1Rlu9602gpnJWwU19gqP8416k4xMBpyN4sa+UAZzvlboCn0IzNP8m0IJpoaZ/i3RQl Xdy9LHgl5C3xYnHlLyNnlCTGKRtufjEHJ7DFsF9CLtv1M7IYJWCh1Z1bxJlq339PVR cvk8TpEvcxKAfSD7c8lgIVmxB5b/AuaBE/40gXdoImdbwHadW7dcYqCODr8hBvs1WN QL1lASbFL7eaIUYpogUyH3TRLAZleuaV4CIEi8LdMEBX8MTlyOOwBTQvx6/pzmc85s Wfvrhnv7sKk3w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4C0ClR1whDz8sYX; Mon, 28 Sep 2020 08:48:19 +0200 (CEST) From: To: Benjamin Kaduk CC: "draft-ietf-dots-server-discovery.all@ietf.org" , "dots@ietf.org" Thread-Topic: AD review of draft-ietf-dots-server-discovery-10 Thread-Index: AQHWlQc4DIVRP4jtWEKZt5Ib47twoql9m9Lg Date: Mon, 28 Sep 2020 06:48:18 +0000 Message-ID: <9185_1601275699_5F718733_9185_137_13_787AE7BB302AE849A7480A190F8B9330315484D8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200918202211.GI89563@kduck.mit.edu> <17479_1600698186_5F68B74A_17479_404_1_787AE7BB302AE849A7480A190F8B933031543746@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200927194841.GD89563@kduck.mit.edu> In-Reply-To: <20200927194841.GD89563@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD review of draft-ietf-dots-server-discovery-10 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 06:48:23 -0000 Hi Ben,=20 Thank you for checking. This is now fixed in the updated version. A diff from the previous version = is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-server-discovery-11 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: dimanche 27 septembre 2020 21:49 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: draft-ietf-dots-server-discovery.all@ietf.org; dots@ietf.org > Objet=A0: Re: AD review of draft-ietf-dots-server-discovery-10 >=20 > Hi Med, >=20 > Thanks for the responses (and the follow-up link to the staged > changes). > Just covering the remaining topics inline; this generally looks > good. >=20 >=20 > > I don't understand yet > > > why/how this scheme ends up being safe, and am hoping that you > have > > > a head start over me on doing the analysis :) > > > > [Med] Returning both the address and the RI in the DHCP prevents > redirecting a client to a "fake" server if the DNS queries are > intercepted. We don't have this issue if both the address and the RI > are returned in DHCP. >=20 > I think my main concern here is that we get back a name to use for > authenticating the resulting connection, but then are told to not > use our normal procedure for establishing a secure connection to a > named entity. > In theory the PKI structure should protect the communication no > matter how we decide to establish the connection (we trust the CA > and the name is certified by the trusted CA chain), but this kind of > short-circuiting can make some classes of attack easier -- if an > attacker can get a fraudulently issued cert, this mechanism lets > them send the victim directly to the attacker's machine without > needing to also adjust the DNS/resolution path on the victim. Your > example of a split-DNS case seems apt, but we should probably > mention the loss of "defense in depth" against mis-issued > certificates in the security considerations. >=20 > Which risk is more concerning (DNS spoofing vs. mis-issued cert) > will probably depend on the deployment specifics, including DNSSEC > (non)usage, so we will probably just have to document the tradeoff. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Sep 28 15:36:56 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 8DB3B3A0853; Mon, 28 Sep 2020 15:36:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk CC: Valery Smyslov , draft-ietf-dots-server-discovery@ietf.org, dots-chairs@ietf.org, kaduk@mit.edu, valery@smyslov.net, dots@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160133261306.23309.11214752757914022775@ietfa.amsl.com> Date: Mon, 28 Sep 2020 15:36:53 -0700 Archived-At: Subject: [Dots] Last Call: (Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery) to Proposed Standard X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 22:36:54 -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) Agent Discovery' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-10-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies mechanisms to configure Districuted Denial of Service Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. Knowing the appropriate DOTS server for a given location can be useful to engage mitigation actions even in cases where the DOTS client cannot localize the attack, but only knows that some resources are under attack and that help is needed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 28 23:03:00 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 959A23A0657; Mon, 28 Sep 2020 23:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <160135937956.12590.11708291726968803638@ietfa.amsl.com> Date: Mon, 28 Sep 2020 23:02:59 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-12.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 06:03:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Jon Shallow Filename : draft-ietf-dots-telemetry-12.txt Pages : 107 Date : 2020-09-28 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal Distributed Denial-of- Service attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 28 23:06: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 52B2A3A0769 for ; Mon, 28 Sep 2020 23:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yceAhNcUH_N6 for ; Mon, 28 Sep 2020 23:05:59 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09F03A0766 for ; Mon, 28 Sep 2020 23:05:59 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4C0pm605zsz113Z for ; Tue, 29 Sep 2020 08:05:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601359558; bh=W79I/mvNXz5bpHxbwZhwkrMBOfwKf2raE3Genk1bTjY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=H+/jsycgPvGfXaW4YMgbMIbxjUV61feCyqlzvJtTszVPwd0SiMQ7WXEhCguvhXJq8 M03AKWkKJvO40PxPOSwSOLKViPVBAWCXLJWPw8WNVTmvEW46V49USD36IMsBoKhkLm 5q8jADvhvjWFoFBdNrPMbm/weE6ZYyCZ7fsWeO3J4SZM3sGIjoBPxtkOxSZP3b9Lh4 s3NwPd5Zxd/qSjldgYdhTHZyVzgIMM6LsZAmF1k6ROwjeF6CxWXmALRTaB9F9FbvXp DG1LDAd5YI1QtuKDxDNQsvzSzgocy7yFg09et+GY+z9VI3o59THeZJ6bbudZyDgGKu Xn8Wt16WrZfFA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4C0pm56cNCzyQ3 for ; Tue, 29 Sep 2020 08:05:57 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-12.txt Thread-Index: AQHWliYzztt1CH5zBkqNw/2eIPM0MKl/IDgQ Date: Tue, 29 Sep 2020 06:05:57 +0000 Message-ID: <5659_1601359557_5F72CEC5_5659_420_1_787AE7BB302AE849A7480A190F8B93303154A031@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160135937956.12590.11708291726968803638@ietfa.amsl.com> In-Reply-To: <160135937956.12590.11708291726968803638@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-12.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, 29 Sep 2020 06:06:01 -0000 Hi all,=20 This version refers now to the RFC8782bis draft.=20 The YANG module is updated to reflect some changes made in rfc8782bis.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mardi 29 septembre 2020 08:03 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-telemetry-12.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of > the IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Jon Shallow > Filename : draft-ietf-dots-telemetry-12.txt > Pages : 107 > Date : 2020-09-28 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal Distributed Denial- > of- > Service attack mitigation. It specifies the normal traffic > baseline > and attack traffic telemetry attributes a DOTS client can convey > to > its DOTS server in the mitigation request, the mitigation status > telemetry attributes a DOTS server can communicate to a DOTS > client, > and the mitigation efficacy telemetry attributes a DOTS client > can > communicate to a DOTS server. The telemetry attributes can > assist > the mitigator to choose the DDoS mitigation techniques and > perform > optimal DDoS attack mitigation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-telemetry-12 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 30 22:01:29 2020 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089E23A0A66; Wed, 30 Sep 2020 22:01:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dots-chairs@ietf.org, valery@smyslov.net, kaduk@mit.edu, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160152848648.28334.16385662154356796075@ietfa.amsl.com> Date: Wed, 30 Sep 2020 22:01:26 -0700 Archived-At: Subject: [Dots] dots - Not having a session at IETF 109 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, 01 Oct 2020 05:01:27 -0000 Valery Smyslov, a chair of the dots working group, indicated that the dots working group does not plan to hold a session at IETF 109. This message was generated and sent by the IETF Meeting Session Request Tool.