From nobody Wed Dec 1 02:15:45 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C66E3A0930; Wed, 1 Dec 2021 02:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 OeZzRZ5zh9tS; Wed, 1 Dec 2021 02:15:38 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80053.outbound.protection.outlook.com [40.107.8.53]) (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 572C33A0929; Wed, 1 Dec 2021 02:15:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N4ckFKGxeeewlBNvCrOpwQcpv1InvSqSObYJNNriMgmhWHOBpdOylajhvUJWkYaDz/s3k2YkqhcPPueYVp5cUqhnfnmPnxTtqM5kbF6gV4YiCTYK9AnRXX1UGXIlflusIQdo1tAL6+oWZnGiRt1ntPYOFnh82haT5oqypyiGFKay+VuFY4tpE3stm5obvfCbX1eZf4vwP73ysohM6w3izcvXOWtzl4MjOFxiKZScNeHPk3+aarDOaXakgsVnz1Xdn07CT4ShfgEC/nCtLOP/ju/KqeTzQN0yVKiq/lvUEWrldhkJeMm7jqxDtpI8ykJjiTNi1E1/BJz7EP4B35uqNg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tFB+Eopk/l0n4bsTSYiidWokGiyCW+03tHgmg8mKZlw=; b=YDroLAckNmxzlaqh6yFCwoJJHGS5TxsmYxt4AimYvrW21saaTiCbTyWCCJPLmvbncet2DOCMBAYJGvHrty7Y6xO/nXF6PoEYRTBiPqrB5pWlt9OWrKIJTVS4W7tNwfMga0vwh799Gf/7bZd4CGfNJ1LWV18AO7NzmHyhFYDYK7DaeoMDb/H3173wTcUdqPEzHOyLTXrEOQ0Vuzh0P+BaSI1/kdXyXmJTmwuT/bTZmxIZ06apTBc/jUCkJvbgk+CyAK54V+wmQHjWHP4COBrkwdmlH3259attaPXYMK++71uhTZOoSiHdp5DvBMuE7soRWh8rLmzY6WNyU9atV9idBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jisc.ac.uk; dmarc=pass action=none header.from=jisc.ac.uk; dkim=pass header.d=jisc.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tFB+Eopk/l0n4bsTSYiidWokGiyCW+03tHgmg8mKZlw=; b=iXJWx+andqfG4SMdyrNsZidq1iAsAfrOVqIsvhuUcvV79/uVDu1usyTaWypE8G6ptWbgLP6UHkl5T5Z0KXhYGidW1FFCap0TsrBDg7eaZWek5WTPcpu0pemhdQBTOfQFzRIkT2RpITlFAZ6vKVHoaOpvE1LXpb2SSghNB9HPdfE= Received: from DB9PR07MB7771.eurprd07.prod.outlook.com (2603:10a6:10:2a6::15) by DB7PR07MB4812.eurprd07.prod.outlook.com (2603:10a6:10:63::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.9; Wed, 1 Dec 2021 10:15:30 +0000 Received: from DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::ac94:792d:33b:2a59]) by DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::ac94:792d:33b:2a59%4]) with mapi id 15.20.4755.012; Wed, 1 Dec 2021 10:15:30 +0000 From: Tim Chown To: "int-dir@ietf.org" , "draft-ietf-idr-bgp-ext-com-registry.all@ietf.org" Thread-Topic: INT DIUR review of draft-ietf-idr-bgp-ext-com-registry-04 Thread-Index: AQHX5pxefqF6gfZYz0KFOEeDcoLVKQ== Date: Wed, 1 Dec 2021 10:15:30 +0000 Message-ID: <19640D05-F853-4C43-BCAE-B107439F544B@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3693.20.0.1.32) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jisc.ac.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffdb55df-7272-448f-0738-08d9b4b3810a x-ms-traffictypediagnostic: DB7PR07MB4812: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ADEJTnuUgvshRDe0ijlCx0tbiQyDC+jz799fIQzYLx1oInjElu0liY9B+KW5EreTge21Ix4v6+y0KFsdm0rnzFqSBRHYiAKFM+ixRFw6AtiBukp7DfJU5TCar6j5wOrMg4aztdVIAnIuE5xJZrgFuehvJ2wY8bdPd+ZMbUpqtGyxuMOGsJZOOA2JKcLBYhqmD6vIlUZg1p9eGEbNKU2OwxxIqvQBiSXvmTPcpz8dHk40RdKjEL/MDviUOe65YIqbDC8gKROapG1eXz4F0Bp7I92MNuda0r5yJIa5Z+Q4TuzIHvaeBUyBi/oHscV3B7AjpQqd+MAXRgv79uuT/Wi1jPwudod6hf08SijnQkvEWP49WR5Gi6fRQA5heePD1d0JI/ehs09HYLOp1a9wkj9yZSRiv0KUoPMrQdVqwQFqh9UqagtRs0acSHpHW/2SWjSS7GTGRWZ/lpoFj0V10WATFdDvE5JTmLxivXMdkzkkrN6YRuBugjjy5aJc7nHQhuUVaXawBiymTnl2jwDq8+ZK+xJhytvhjbbqxiqMa+QUTeHK4Whhb388d8pDksltwFPklL2iurWxCb5SdiMe47y0J6+y4kVuBXpQRdAzkKBwqw/eLTdavWnxn/urmbE4wAcf7hqMEu/6AAsUgwKJ3l8gRBIqLcvDfs7PrQJTm8D25CmGHX60DAqiSWAlUK/nHZghq2Zs5InyyPkt3Jh2mtGCEzDawHq7CpHvk6EFzLcQHyMZpxe424FRk23gw/OLTI7EKBkjp2AJABjKyEv4hhLW0lki5p/mmCirr3XYuFRIpvj6FjovZGgSuB9OMKa25K57 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR07MB7771.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6512007)(33656002)(38100700002)(6506007)(186003)(786003)(110136005)(966005)(38070700005)(508600001)(316002)(83380400001)(2616005)(122000001)(66446008)(66946007)(8676002)(66574015)(71200400001)(76116006)(5660300002)(8936002)(36756003)(64756008)(66556008)(450100002)(2906002)(6486002)(86362001)(91956017)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RHM5dGtpaVlsOVZ2eGdnL2lkLy9ZOElkcGlHeUViaXhOcDg1Q2Vjd1I5cDhZ?= =?utf-8?B?MEN4WTRpUGsvcThNV2Znd1BDZVhOdWpCQm5qWWdGL1lMajI1U2NPaTAraHI0?= =?utf-8?B?NUR5QVdkWlJQL2Z5U3drWU5IMmF5YjdGWWdGbW95bkIwc3JIWVFSQXpOVXNU?= =?utf-8?B?VlQrYmdPbERkNG00OEUwVmE4U0cyZGkyMkJicStWUUR6SFlUa2lTVTZZSk16?= =?utf-8?B?VVR4TGVJWkwzYXR1Y25CQnJ5WDBFY3c4R1JkaTZrTEJVdkVrRWZ3SzQzZDZY?= =?utf-8?B?LzNhWTUyeEZoWE9MYTdlQjNONWk3NnBZK2I4TlptNnJJcStrR2QzUUVSNzdB?= =?utf-8?B?cXQ3VzBvc29zUEgxZEZycWNPRlUvKzRZeVNxL3BoY3BnamNmRHFFUXJjMjJs?= =?utf-8?B?enJnTEl6NERzbXBVK0FXamIrZmVqNFl2dDBZdDFhUnYvT3ZMYXdxTk1yQTVD?= =?utf-8?B?WjNncUtnaXFnKzBWSENnS29jZ2p5ODNaM1kvUUIrN3JSbUk4T05QRmtCOWpt?= =?utf-8?B?Wm5KZVJVK0dXWlp2MjE4Rnd2Wmh4SVpNUC9MRWlpVWpVcStzZ2J4UDN1MmFi?= =?utf-8?B?Wk5QRVhlekJWVkh5dkl4ajQzb290ZW10Q3ZVZTdjVlZmc0QvR1JxWXpyWGll?= =?utf-8?B?VDFLemdpMnQyZkM5c3Z5d2l0SG9sTkJ0Kzdaais3ZXhab3JBNUZCTkYwMGQ2?= =?utf-8?B?RDF3ZS9XNTlrQzBKbFlGMlZXSE9JdVk0V2wrbEJXR1llSDJWNWRqcmJDM1dO?= =?utf-8?B?emRSMFVWVlc0SkZ2MW9DTHkwWllFWGt3UTRHS3MwMTBLRlJ5RzZqYTNOYTFY?= =?utf-8?B?clI2dGxZb2tOZGZWVWtMRG12QkJqRnRUVDdwbGhZZ0FrY2dyUTdqVldhOFBo?= =?utf-8?B?OG84T2NTdUMvbVFieUdPd3ExR0l6a0ozMHBSVDRMZGJPUmR2Sk1YazU5V2t2?= =?utf-8?B?TzNnOTBMQ2NxcWRveFRqWld5eURuQnVXSHgxRTA1Nk9OZDh0R0VLS2lCaEtZ?= =?utf-8?B?TUxLWFRnTmxwM3FLOHliMVJET2pESzc2b1phT3prcEVqaVc2RHZDb0JVSnlN?= =?utf-8?B?Y1ZOSzZFdllqbGlGbTVpbzNpaGQzTjBla1lERnJRUnBqd1gvbmJSaERzbkFH?= =?utf-8?B?eFNIU1NPZlIvdWtteUVUdFZjYmFCMnVHUC83NDZUVTMvVEk3Ly9YUFdTRjln?= =?utf-8?B?QTZ1ckkxdW56S1haMFF1aWErOXhGWFpLM0NUaWNLTENWUklxUkNzb09aMVVv?= =?utf-8?B?UjkySnBDNmV2QmQ1YzdSdHJqWWpJM0FxbjhydmZza3NwUzV4M3JYTXBiZFBz?= =?utf-8?B?SS9WdnkyVGVHdm9RcmZuZUdWOE5PWE9JTlNQdHhLT29GNjZzbHlCZ2pTaUVh?= =?utf-8?B?TU1GTElwQ2RNTTM0VnM3ZWxXMlhoSUduZnhHUk40M05nelg4cnl3R3JTN2Mw?= =?utf-8?B?a2tJano2Y21VbVcvM2cvWXNHWXF2dGZsNnJWa3NXU21aTENYS0Q4dWNXWjZx?= =?utf-8?B?U2d6MndoUEZJdktiS0tKUnBhUFdNZStOa3lFWFNlQ3E3Z2tOalY5aDVVS0l0?= =?utf-8?B?b2JWRmlkN1RadENaUEZ1bTFTdUlYNlpTN0p4bXlGMmorTUR0VXNzTllNNkRT?= =?utf-8?B?elFHOXNEK2Nxc1lvMWkrNXV5TUJkQXJDUXFaNUlYSDArZFJmZEkwNkxFbWxK?= =?utf-8?B?QmwvN1JZWm80cUFNZXFzWnFEYldWNnVpd01HTENCR3l2MEhheFhBSzNRQXQ0?= =?utf-8?B?SGlxRGpjalRXVEFtQUpOL3k0VUxpc20zblJ4eUE2d09vK2dRcVhMSE9Dek5D?= =?utf-8?B?TDdFSDFXSkszeFpYVGwvSFJpVGVMS21JVjhLWERQNFd6ZnhZRDI3MzRrQjA5?= =?utf-8?B?QUM1anNXdnlyRnBUcEZ5ZlIwUDJsR1hWaXFHU2RTM2llZjZTckRBdHI5VmNj?= =?utf-8?B?ZUhweHNVY1hSVHp6WHIrWDZSdGdaa2RXUThFUlJSQmt2QjN0THpKbmoydnRK?= =?utf-8?B?dlBpVVhCalBFNDVUdzZZYzVmZnRkZ3NnQThUckQ1TEErU3lmaWMxSVAwVmdM?= =?utf-8?B?TStKZlNhUlhtM0NXRGZ3TVUrY2E3aGdKS0RSc1BSMDROV2orTVZISWhxZHVS?= =?utf-8?B?R01hN3dULy9NMEJvRDNxZnQ1cHlvV3p2djNxSTB5RzRFalhCdmh5NWI2M2NZ?= =?utf-8?B?MEdXd2pTZG9SQnY5cEprQU1NcE1UQnQvbzllckx4aDJPeVZMZ0JScjNPVUVT?= =?utf-8?Q?KafcJIvanTfTtiCh22l7Bag86RBPMnomecmiP6MqdY=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR07MB7771.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffdb55df-7272-448f-0738-08d9b4b3810a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2021 10:15:30.5762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CvvDHotjpyQhIeuQ70RpKEjqwf7yuNTxAZ27bt5deU0/f4FylXgrJ1mmwRn3oro1QjoWw47QE+TQsJw+nrKa1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4812 Archived-At: Subject: [Int-dir] INT DIUR review of draft-ietf-idr-bgp-ext-com-registry-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 10:15:44 -0000 SGksDQoNCkkgYW0gYW4gYXNzaWduZWQgSU5UIGRpcmVjdG9yYXRlIHJldmlld2VyIGZvciBkcmFm dC1pZXRmLWlkci1iZ3AtZXh0LWNvbS1yZWdpc3RyeS0wNC4gVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWEgRGly ZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBzaGVwaGVyZChzKSBzaG91bGQgdHJlYXQgdGhl c2UgY29tbWVudHMganVzdCBsaWtlIHRoZXkgd291bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkg b3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kIHJlc29sdmUgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQuIA0KDQpGb3Ig bW9yZSBkZXRhaWxzIG9uIHRoZSBJTlQgRGlyZWN0b3JhdGUsIHNlZSBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2dyb3VwL2ludGRpci9hYm91dC8uDQoNClRoZSBkcmFmdCB1cGRhdGVzIHZh cmlvdXMgcmVnaXN0cmllcyB0byBjaGFuZ2UgdGhlIOKAnEV4cGVyaW1lbnRhbCB1c2XigJ0gcmVn aXN0cmF0aW9uIHByb2NlZHVyZSBmb3IgY2VydGFpbiBlbnRyaWVzIGdpdmVuIHRoZWlyIGN1cnJl bnQgcHJhY3RpY2FsIHVzZS4NCg0KVGhlIGRvY3VtZW50IGlzIHdlbGwtd3JpdHRlbiwgY29uY2lz ZSBhbmQgZWFzeSB0byBmb2xsb3cuDQoNCkJhc2VkIG9uIG15IHJldmlldywgdGhlIGRvY3VtZW50 IGlzIFJlYWR5IGZvciBwdWJsaWNhdGlvbiwgd2l0aCBqdXN0IG9uZSBzdWdnZXN0aW9uIC8gbml0 IHRvIGNvbnNpZGVyLg0KDQpOaXQ6DQpUaGUgZWRpdHMgcHJvcG9zZWQgdG8gDQpodHRwczovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9iZ3AtZXh0ZW5kZWQtY29tbXVuaXRpZXMvYmdwLWV4dGVu ZGVkLWNvbW11bml0aWVzLnhodG1sDQphcHBlYXIgY29ycmVjdC4NCkkgd291bGQgc3VnZ2VzdCBh ZGRpbmcgdGhpcyBleHBsaWNpdCBsaW5rIHRvIHRoZSBkcmFmdCwgZm9yIGNsYXJpdHksIHJhdGhl ciB0aGFuIGp1c3Qgc2F5aW5nIOKAnHRvIHRoZSByZWdpc3RyeeKAnSBhc3N1bWluZyByZWFkZXJz IHdpbGwgZmluZCBpdCBlYXNpbHkuDQoNClRpbQ0K From nobody Wed Dec 1 03:15:14 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAE13A0139; Wed, 1 Dec 2021 03:15:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tim Chown via Datatracker To: Cc: draft-ietf-idr-bgp-ext-com-registry.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163835730757.17463.907565690725141641@ietfa.amsl.com> Reply-To: Tim Chown Date: Wed, 01 Dec 2021 03:15:07 -0800 Archived-At: Subject: [Int-dir] Intdir telechat review of draft-ietf-idr-bgp-ext-com-registry-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 11:15:08 -0000 Reviewer: Tim Chown Review result: Ready Hi, I am an assigned INT directorate reviewer for draft-ietf-idr-bgp-ext-com-registry-04. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . The draft updates various registries to change the “Experimental use” registration procedure for certain entries given their current practical use. The document is well-written, concise and easy to follow. Based on my review, the document is Ready for publication, with just one suggestion / nit to consider. Nit: The edits proposed to https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml appear correct. I would suggest adding this explicit link to the draft, for clarity, rather than just saying “to the registry” assuming readers will find it easily. Tim From nobody Wed Dec 1 03:35:41 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DE13A043F; Wed, 1 Dec 2021 03:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EMwfZhvG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E7GEZbfp 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 Ph5spPJniu41; Wed, 1 Dec 2021 03:35:36 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1123A040B; Wed, 1 Dec 2021 03:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2234; q=dns/txt; s=iport; t=1638358536; x=1639568136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qlQMcMxPlYGkLray/zE3arsw/BQ163K7ccKo4fTyqtM=; b=EMwfZhvGelSIBUiAzVayEtqyiKvvwyKtpsp0Is4t8JH7UiNwS/2+WEsJ J87YmU2jtbbzoxrYtJo6yCyzOUdp/BdRByUQf9/ZLLfHlTHPLzde3SNDK 5AOfoLp+dQspMA89ntp6ZGAzRufFB01C7W+uWUfQwh2WLAQQAEEeUa4cF 4=; X-IPAS-Result: =?us-ascii?q?A0D3AABLXadhl4MNJK1aDnuBWYFSUX5aNzGER4NHA4U5h?= =?us-ascii?q?Q6DApsRgS6BJQNUCwEBAQ0BASoNCgQBAYUEAheCawIlNAkOAQIEAQEBAQMCA?= =?us-ascii?q?wEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAR0HBgwFEA4nhWgNhkMCAQMBARARE?= =?us-ascii?q?QwBASwLAQ8CAQgaAiYCAgIlCxUQAgQBDQUigk8BglUDLwEOo2kBgToCih96g?= =?us-ascii?q?TGBAYIIAQEGBASFCxiCNQMGgRAqgw6EHocGJxyBSUSBPByCZz6CYwEBA4FdF?= =?us-ascii?q?4MBN4IukSY+JgQvJBQ8CyRMGSQLkjSDWqkvCoM8ilaOS4VnBS2nNZYbH4xam?= =?us-ascii?q?RYCBAIEBQIOAQEGgWE5gVtwFTsqAYIKATNRGQ+OOYNZhRSFBUV0AjYCBgEKA?= =?us-ascii?q?QEDCZJsAQE?= IronPort-PHdr: A9a23:CJ78xRBBiKP8Q08JsTPzUyQVaBdPi9zP1kY95pkmjudIdaKut9TnM VfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKWkwJjMwMlFkmB8iIQUTwMP/taXk8G 8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH0aXCA== IronPort-Data: A9a23:ulJjRKoYfknGv5iDac327hnLCfheBmLfZRIvgKrLsJaIsI4StFCzt garIBmFMq6PNDOhed8kbIqx8UIPvZTVzNQ2GgU4pCxgEiMR9+PIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkS5TE3oHJ9RGQ74nQLlbHILOCan8ZqTNMEn970Es5w7dh2+aEvPDga++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFJZH4rHpxdGlOjKmVi8kFWc M6YpF2x1juxEx7AkbpJmJ6jGqEBaua60QRjFhO6VoD66iWuqBDe3Y4WMdAeWW1upw+33OlIw /xIm4a6GV8Qa/ikdOQ1C3G0Egl3OalAvbTAO3X66IqYzlbNdD3nxPAG4EMeZNJDvL0pRzgVs 6VDcVjhbTjb7w6y6L+lW+9nhckLJ8jwN4RZsXZlpd3cJaZ+GM6eEvSUvbe02h8onsJoB/HVX /NGeB9RLznScgdKHQs+XcdWcOCA3ymjLGIwREiujaYt6mbPiQ18zLaoMdbPP9aFXYBYjlrdr WXDun70DRABKMaOjzOB9lqti/PB2yThV+o6Fbuks/JrmnWSy3AdThoMWjOTvfi8zEW+XM1ZA 04V4SFopKN06U/DczXmdxS8pHjBtRkGVp8JVeY78wqKjKHT5m51G1ToUBZsbfYkhOUPaQYUl WawlPrsKyZl4OWsHCf1GqivkRu+Pi0cLGknbCACTBcY79SLnG3Vpk+TJjqEOPPp5uAZCQ0c0 BjR93Fn2Ot7YdojkvTlow+W2lpAs7CQFlZd2+nBYo6yAuqVjqaMY4il7zA3Bt4fcd7AFTFtU JX48vVyAcgHCZWL0SeKWuhIRfei5u2ON3vXhlsH83gdG9aFpiLLkWN4uWwWyKJV3iAsImSBj Kj74lk52XOrFCH2BZKbmqroYyjQ8YDuFM7+StffZcdUb556eWevpX81NRTBgDi1yhB1ycnT3 Kt3l+7xXR727ow6k1KLqxs1jNfHOwhnnzqIHMCnp/hZ+ePDOyb9pUg53KumN7Bls/zsTPT9+ NdEPMzC0ARETOD7eUHqHX07czg3wYwALcmu8aR/L7fbSiI/QTFJI6KAmtsJJt0694wLzb2g1 i/mBSdlJK/X2CSvxfOiMSgzNtsCnP9X8BoGAMDbFQryhiV4P9/wtPx3mlleVeBPydGPBMVcF 5EtE/hsyNwWItgb01zxtaXAkbE= IronPort-HdrOrdr: A9a23:cBGN9qHB6PwDGD+HpLqFuJLXdLJyesId70hD6qkvc31om52j+f xGws516fatskdvZJkh8erwX5Vp2RvnhN5ICPoqTMmftW7dySiVxeBZnMrfKljbexEWmdQtrp uIH5IObeEYSGIK8foSgzPIUerIouP3ipxA7N22pxwGIG0aCNAD0+46MHfnLqQcfnghOXNNLu vl2iMxnUvYRZ14VLXeOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPIf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcBcsvy5zXcISdOUmQ8Xee r30k8d1gNImijsl1SO0F3QMs/boWwTAjHZuAKlaDDY0L3ErXoBerp8bMRiA0fkA45KhqAj7E qNtFjp6Ka/RCmw7hgUrbLzJmJXv1vxrnw4neEJiXtDFYMYdb9KtIQauFhYCZEaAUvBmcwa+c RVfYvhDcxtAB6nhrHizx9S6c3pWm52EgaNQ0AEtMDQ2z9KnGphx09dwMAEhH8P+J80VpEBvo 3/Q+pVvaALStVTYbN2Be8HT8fyAmvRQQjUOGbXJVj8DqkIN3/Etpay6rQo4+OhfoAO0fIJ6d v8eUIdsXR3d1PlCMWI0pEO+hfRQH+lVTCo0c1a74gRgMy2eFMqC1zKdLkDqbrVnxwvOLyTZx /oAuMiPxbKFxqYJbp0 X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.87,278,1631577600"; d="scan'208";a="801659960" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Dec 2021 11:35:35 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1B1BZYTP024549 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 1 Dec 2021 11:35:34 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 1 Dec 2021 05:35:34 -0600 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 1 Dec 2021 06:35:33 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 1 Dec 2021 05:35:33 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dlS44aPpSK7b3l96L5ZMiYWoren8xj2sYV6nwXcWF1dDEItMrFcQbNocqsPz4P+VkIEfmru3RpW+WAzgi11McnQ2xlQ0136+YsJeFuVE4vcL3mn7Eg6Ga++CM5C8euzi++DFDWNJT7aRZwpQA/GRYx8+sTfvIysQRP/0/+VAfHfOkhCT025vcqF0NdDaywOthB9MQ8dByiu1tj2iA5INCXkoxauqXZJ73fVX/UWcFs5B6BqAmXEc6eki6pmE3h0o1KwxaMHDiktJSB/vT01WyxXniCVz6eqCg6HwraxvFBn0d1YolBojrRZo4i9MMCxaMVDPt85jHZGZ1It0Wf9W9Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qlQMcMxPlYGkLray/zE3arsw/BQ163K7ccKo4fTyqtM=; b=UAgG00595z9l/neJ7eVD18IqXQLxzFw3CqEnH5NUsU18x9Zr+MntGQU6aIgLHWmIjdTOJ5hzIDvcna2OXXwpfojM7G/I0C6gz7JlrZ8XW1wxQdrFOs4qvrY/WUAZVkzo9hI/7NrZpmGPA0QTLjJiOXjVd3HrLaST9r0lrAwoS4n2MUsEZGlFz9c/t58DIobCfk3gLmiVrxWSoChUrc54JmTiE4h/S5m0qrtZ6hpjvXF21w8MRpwatDsM9KvJKDk+a0pNQrYYUJhBwP7AgraqKMWF2cr2qbRjdE/fLfQI8iBS7hPXQBon+6Yegl8gQew8Qcpv9QVJhwWuY14bwF9HGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qlQMcMxPlYGkLray/zE3arsw/BQ163K7ccKo4fTyqtM=; b=E7GEZbfp4QFgR8KsmeOUa3IntNQh/bArtUUt1r4D/wWMyfFD/joL1IV45IYzQTDXp7rRZYFryyXlD7+XCVakgLengI+v4pYLU2IllNXa3I5Vgj8oIWXMw2hO7w8QFmpTqsNL+QjhR1ILEITQ5GOImZ5mtF8+5MDMZqNSwBzQVrg= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH7PR11MB5861.namprd11.prod.outlook.com (2603:10b6:510:133::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.15; Wed, 1 Dec 2021 11:35:32 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::fd55:3032:c8df:edad]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::fd55:3032:c8df:edad%3]) with mapi id 15.20.4734.024; Wed, 1 Dec 2021 11:35:32 +0000 From: "Eric Vyncke (evyncke)" To: Tim Chown , "int-dir@ietf.org" CC: "draft-ietf-idr-bgp-ext-com-registry.all@ietf.org" Thread-Topic: [Int-dir] Intdir telechat review of draft-ietf-idr-bgp-ext-com-registry-04 Thread-Index: AQHX5qTCNBoe69LsiU6F+or0zMvSiawdkpGA Date: Wed, 1 Dec 2021 11:35:32 +0000 Message-ID: References: <163835730757.17463.907565690725141641@ietfa.amsl.com> In-Reply-To: <163835730757.17463.907565690725141641@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a5c6329-e59a-4076-6a2c-08d9b4beaf0e x-ms-traffictypediagnostic: PH7PR11MB5861: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JXTtYeC5kU+WRcrW6JVKD4AcKlDvYKPKOAvW/FG3pOSHMCwr8Vaprh9o6ydiNtmQzmPCH3ViUHIb0haku2M0elXNrEWAi6+GiimuqHkECFyY1mTqsAYTz0NDqlXB5+Z0LpTa55O+tHIK/eJU1/46g0Y8WjQwN3v9YBneoIB6bbs1ZEG5C6xjhVoAS3zhr38TvbzISJunWyiN1ZVz73pU/9NcQ/GrePpCQY/1/sRltE9jvsuieGjjKW6JVH90HtTwS/sYCH7krG+9HWujoqwFha+lrPASNP7dEmukuQAFA7fhVNYufCDwcGAdf2vRByZzo3/ixHYRGahap+ToMyEPqZCH1X4vZQ8vAKWMcEJO3HBgLPElelRh/XdEyyqk4uDx+VWVtADqphMoMxwrC2z9QDfYsBur8HVAcL64+1gtFsOMh3y3U9R9aSTSn1KVwqou+V9oyFqlVb63GWNspRbNg2UyQYF0pSLj+WXWgCCyxP0GENO6t07FDMvsLmr5CJkLhKTCe10hg3f29qjw1tAk5V0mJ1EQEHWzKPVvPjw4gDnIy1xBf7i0Sz7TpuaJqvw5kEWMmuSAakkRXwAHEyhLg2G93HiUyw4fnzan82Z415pyRMiVGMA+04u7Y6YB05M2HXUF69pUcu8j9GTSVkwSbgXK9qG8CmjAHJz75sFpxE2mOcizGNd6lVg1zUq2r8KI2G8M5U5bSnObCwTySpAguO3XkOr5MfRLPQ53qXMI6Qs+lxnMpTlUWX5eFAMJhgAo9/FBsBOcu71q2FljBgv/6ICw/GbV6klks5vllDoTjgiBz1qqn2GFM7kVJVMLwRAihSPRqDNc6ziJDpFn5oId3XQQ1vdRJJ+ZuEG3vsfxxGU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(38070700005)(66476007)(2906002)(6512007)(8676002)(122000001)(66946007)(2616005)(66446008)(508600001)(8936002)(91956017)(316002)(110136005)(4326008)(86362001)(76116006)(66556008)(966005)(186003)(83380400001)(5660300002)(36756003)(71200400001)(38100700002)(33656002)(6486002)(66574015)(6506007)(64756008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aENtdTVEWXhuUDNpWWtGczhqUkVOc2xlQVZNeml2MU5mTlRpdzN4bUh2cFJ2?= =?utf-8?B?VDV3VnJoWmJIZ1RSREtlR1dVWFlKVnRud1pBMEViT2ZsTGJIamZFckp2d3ZW?= =?utf-8?B?WWREdERmVG5KVHkwNEFjUmxBbE9oTkRZQTk3VXJWVGx0ZjNzRG10Ym1aSHI0?= =?utf-8?B?eEJZSllmZ0FOeXl4b0Jscy9VejZtT2J2cUpSSkV2TG5aSEI1WjZHb0xMdncz?= =?utf-8?B?K3QxRHY2ZitndXlTSkR6Z3ZrTmJENTVKM3lxK2dOM3E0TElQYnlFSk12OFVT?= =?utf-8?B?MU5ENmdickV0czJPbTJ3d0JrYVNvVGcvSGJuZVlHbG9DWWlYMjdWWWhDNUZY?= =?utf-8?B?bkgzb3Z6M01sVlQrYmorRXppajRCOHF2M1JIdGlnTzM1RHJWak80dDI4SXNO?= =?utf-8?B?Vng4K29NRWJvNm9KanE5dzN1b2NrenNzRW5scFJ4U1pvTmNDWTJFbWNEMXRF?= =?utf-8?B?R05HYXI1Mm1HNEpiZ21GMm5LcFFKYzF6ajdnUC9xOFE0SVdmWXowY1ZMUTQw?= =?utf-8?B?TC9NNUJNZHpDSUx3THkveEJFZFZpUkdyUzJYMnByWGtSWjdMUGYya2pBd3ZK?= =?utf-8?B?MExoWnQ3M2tNQjZqTExCanJnNldKVmhieVczcld1d2QyQmt1MjMyYlpuZlcz?= =?utf-8?B?eDJLOHlCNTVNK2VLY0xRZ0JBdXQrTFQ1TllwODBIS3lQTk5CUGZodmFiMHZJ?= =?utf-8?B?T3hKU3FMNHNUZTI4TndWNzc5bHF6Y1hWazJNNzZNckxYV1hpQzM3UjdFRGxM?= =?utf-8?B?T1dydlJvM0RBc1ZEZEZydDFMT2N5azhWdlFDN3FESVVBMEUrak1oVUZ6RzhS?= =?utf-8?B?cUVZUkF0cUFRK2VjZFVjUkNvNkxvc3phbXloeVc4RVQ0N2RtTGZIUUNuVWFF?= =?utf-8?B?eEZPYTJFR1F1ZDNRT2NESUtFQXhoSzMwZVBaMWlNUXFDK0o2Sy9oK1VmZ0p2?= =?utf-8?B?NHVyaC9GbS93RkNZb3VCVXpvQVRxNWZSbHRtd1NpSHM0SjlzdUthSDhGODk2?= =?utf-8?B?MWg4VXVYM0szYkQ1YmNpUGo4K254MHZ5UXYzUGlsdHlpYW5ianVMN1ZqOFVU?= =?utf-8?B?dHlXUmdqb1BkV25tT2RPQmtsZ0V6aithbHdIL1k0YnJCdjRzZ3VEQWRHeWF2?= =?utf-8?B?YmZxWmhPRG52Nyt4VEdxeUkwYWxXTzVDcU9zMXRaWk1mUEQ4dnp4K3lZV2Ev?= =?utf-8?B?YWxISHZvYUEvZUtJK3h6dmNWVUdKWlJKcTdCTGdYcWZWNnJoekVmS3M1aEV4?= =?utf-8?B?VWNWQ3RZZnkzcUFQSFZZYWc4UzVUYlIwL1Avb3pCdkRaOUNVN1IzcThtVlgx?= =?utf-8?B?NGxsb2k5THNCaWU2LzJDN2puODVEWENIa2svVkw5dlZpejVyVGsyYmFvaXdk?= =?utf-8?B?NGFFK0Uyd1A3QVJCTGhxT0dHcmRMblhwdDhJd0lGbndiUmJoWGhIbUlsTS8r?= =?utf-8?B?anhPWlBNemdQT0NoZVRnS01MaCtVOWJqbU9pV2xtRERVTW9jUjlsS0FST3do?= =?utf-8?B?VGZNcTh2dzUyRnNXUEJDR1I0bW44UzZMeXBDZ2JoK3V6TndBR0JCUlpsTDFG?= =?utf-8?B?djZXT3RzN0xrU0Z2akRoc0hwTkNNRzJpTlYxb3RoVGswUWYrdFdNZ05kMEd4?= =?utf-8?B?b2NJbHcrWEQ1VlVlYjQrNlRYVFJnOUFPNnFHSzQ1ejBDMG5qOEtZWlp1bitM?= =?utf-8?B?KzJhR0taeHIrNTVTYlYvV0NjNlVoTnhmQ3VuUU5HazM5MjFxVVQrbTgrWFNE?= =?utf-8?B?TjQwUmtoY0xkQnZ1dHNBRzlnWmlNWEJFU2pROTRTNjRxdjE4RnFRNU11Tk1n?= =?utf-8?B?YmhRN0xpSDA2cjNmdjE3N3paTG05K1pkZjVrQmtSZEFKaG1oSmVRZ2srN2Vw?= =?utf-8?B?NFQ5aThxNjZGUkl1cmIvQkZsOTFDRUhmN1ZwbUtoVGtSSjVSU2NxeUQyRUto?= =?utf-8?B?T2p4TmxjRmlsTENpUWJEY2QvOEVEUG5JcGZKckh6UDFKQ09YWVk5cjR4aExU?= =?utf-8?B?Um1ZeTRLdksvWlZwb0EwN2RBMkVVbkRMOUFrYXQyVlRLT2hueU1zL3d3eGNN?= =?utf-8?B?VXFHZGh4eXdzWXhGcEpMWDhhLzdXQ2NTbm8wU1RTUlZ5Qmw3KytMQXE1NTVj?= =?utf-8?B?WkwrZzV3OVRzRHVrWEVCdmtqdldaMkg0UjljeWw1L3JKcnA1T2RSbU9rZkFq?= =?utf-8?B?SzZVbnVNOWhJMy9RWUtlZytRVHVtVDNqTU52eUZ6SjZZckxra1A5R0Vub1Mr?= =?utf-8?Q?tj4zJn4tiSy0salUgzWU82fEv0cfdiPmnsjD5y5Hpw=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <50E3189E357EDD4CB2D31CE849022BA9@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a5c6329-e59a-4076-6a2c-08d9b4beaf0e X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2021 11:35:32.1636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ukEbxKttVkpqnKMBEhXsYsUEH5bBHjxij6oCRzjdAf1pTb9P33uB1YhAMGj4d7aQLKxsf8JALs+qnrkaR9KDiQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5861 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-idr-bgp-ext-com-registry-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 11:35:41 -0000 VGhhbmsgeW91IFRpbSA6LSkNCg0K77u/T24gMDEvMTIvMjAyMSwgMTI6MTUsICJJbnQtZGlyIG9u IGJlaGFsZiBvZiBUaW0gQ2hvd24gdmlhIERhdGF0cmFja2VyIiA8aW50LWRpci1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmll d2VyOiBUaW0gQ2hvd24NCiAgICBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQogICAgSGksDQoNCiAg ICBJIGFtIGFuIGFzc2lnbmVkIElOVCBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCiAgICBkcmFm dC1pZXRmLWlkci1iZ3AtZXh0LWNvbS1yZWdpc3RyeS0wNC4gVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseQ0KICAgIGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJl YSBEaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kDQogICAgc2hlcGhlcmQocykgc2hvdWxk IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSB0aGV5IHdvdWxkIHRyZWF0IGNvbW1lbnRz DQogICAgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kIHJlc29sdmUgdGhlbSBh bG9uZyB3aXRoIGFueSBvdGhlciBMYXN0DQogICAgQ2FsbCBjb21tZW50cyB0aGF0IGhhdmUgYmVl biByZWNlaXZlZC4NCg0KICAgIEZvciBtb3JlIGRldGFpbHMgb24gdGhlIElOVCBEaXJlY3RvcmF0 ZSwNCiAgICBzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9pbnRkaXIvYWJv dXQvIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL2ludGRpci9hYm91dC8+Lg0K DQogICAgVGhlIGRyYWZ0IHVwZGF0ZXMgdmFyaW91cyByZWdpc3RyaWVzIHRvIGNoYW5nZSB0aGUg 4oCcRXhwZXJpbWVudGFsIHVzZeKAnQ0KICAgIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUgZm9yIGNl cnRhaW4gZW50cmllcyBnaXZlbiB0aGVpciBjdXJyZW50IHByYWN0aWNhbCB1c2UuDQoNCiAgICBU aGUgZG9jdW1lbnQgaXMgd2VsbC13cml0dGVuLCBjb25jaXNlIGFuZCBlYXN5IHRvIGZvbGxvdy4N Cg0KICAgIEJhc2VkIG9uIG15IHJldmlldywgdGhlIGRvY3VtZW50IGlzIFJlYWR5IGZvciBwdWJs aWNhdGlvbiwgd2l0aCBqdXN0IG9uZQ0KICAgIHN1Z2dlc3Rpb24gLyBuaXQgdG8gY29uc2lkZXIu DQoNCiAgICBOaXQ6DQogICAgVGhlIGVkaXRzIHByb3Bvc2VkIHRvDQogICAgaHR0cHM6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvYmdwLWV4dGVuZGVkLWNvbW11bml0aWVzL2JncC1leHRlbmRl ZC1jb21tdW5pdGllcy54aHRtbA0KICAgIGFwcGVhciBjb3JyZWN0Lg0KDQogICAgSSB3b3VsZCBz dWdnZXN0IGFkZGluZyB0aGlzIGV4cGxpY2l0IGxpbmsgdG8gdGhlIGRyYWZ0LCBmb3IgY2xhcml0 eSwgcmF0aGVyDQogICAgdGhhbiBqdXN0IHNheWluZyDigJx0byB0aGUgcmVnaXN0cnnigJ0gYXNz dW1pbmcgcmVhZGVycyB3aWxsIGZpbmQgaXQgZWFzaWx5Lg0KDQogICAgVGltDQoNCg0KICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgSW50LWRp ciBtYWlsaW5nIGxpc3QNCiAgICBJbnQtZGlyQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtZGlyDQoNCg== From nobody Sun Dec 19 12:02:15 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 009443A011F; Sun, 19 Dec 2021 12:02:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Lamparter via Datatracker To: Cc: draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, opsawg@ietf.org, mcr+ietf@sandelman.ca, equinox@diac24.net X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163994413394.12070.6171048717943515773@ietfa.amsl.com> Reply-To: David Lamparter Date: Sun, 19 Dec 2021 12:02:13 -0800 Archived-At: Subject: [Int-dir] Intdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2021 20:02:14 -0000 Reviewer: David Lamparter Review result: On the Right Track [I've thrown a copy of this on https://gist.github.com/eqvinox/4e3e96f117b059f65e8a449fbb71738f] Hi Michael and all, I've been poked for an Early Review of your MUD DNS draft. Here's what feedback I have at this point. (I've looked at the -02 version on the datatracker, but I don't think you've changed much in your git repo compared to that.) re. 3. Strategies to map names - plain reverse lookups. Some vendor working with cheapest available developers will sadly understand your list as "oh I just need to do my reverse maps /right/ and then it should work." I'd say "explain in detail how this can fail." is not enough, it might need to be "explain in detail how this can fail even if the vendor tries its best". - the controller doing lookups, (potentially using the same caching resolver) The MUD controller and the device using the same resolver is a neccssary requirement, but not a sufficent one. Worse even, this is essentially a Time-Of-Check-Time-Of-Use security vulnerability. An attacker may be able to distinguish device-originated DNS lookups from controller-originated lookups and give the controller a much longer list of replies while still allowing the device to function normally to cover their tracks. It's fringe (if you can break DNS like that there's probably better things you can exploit), but still. I haven't really put extensive thought into this, but the only pedantically-correct solution to me seems to be to actually track the exact DNS responses that were given to the device. re 4.1. Use of IP address literals in-protocol Nothing says the MUD file and device spec need to specify the target in the same way. It might actually be a good idea to give the device a DNS name to resolve, but just list all the IP addresses in the MUD file. The vendor should absolutely be able to do that in some cases at least (i.e. no highly dynamic changes to the addresses.) Considering all else, this might even be one of the better approaches? On a sidenote, this also means it's wrong for the firewall to try to validate SNI names when the MUD file only lists IP addresses. Technically the MUD file could also list a *different* DNS name that is guaranteed to return a superset of addresses that might be used by the device. Whether this is a good idea I don't know. (Also note this conflicts with monitoring a device's DNS lookups to track the actual responses it received.) Ultimately though what I'd like to note here is that there's 2 different objectives here. The device itself wants a useful subset of addresses to contact. But the firewall needs the superset of anything the device might need to talk to. re 5. DNS privacy and outsourcing versus MUD controllers I honestly don't understand how any device vendor can reasonably encode some specific DNS service into their device and expect it to work. If my network, whether it be home or corporate, has a policy for some specific DNS cache to be used (e.g. on some firewall appliance), a MUD file isn't going to punch a hole into my policy for that. And this really zaps all the DoT & DoH bits at the same time. And with me being from Germany I can tell you we have ISPs that give their users a checkbox to block Cloudflare DoH on their service - not even for technical merits, just because it was a publicity sh*tstorm. (Nevermind the fact that the ISPs may have their own ulterior motives.) re 6. / conclusions in general I'm not sure how far I should go here with review, I'm not involved in any discussions here and am probably missing a bunch of context. 6.5. seems a no-brainer, maybe even too weak of a conclusion. Devices /really/ should use the DNS they get told by the network. 6.1. is the MUD file a protocol too? It's not clear from the text. (I do also disagree on the conclusion, in my naive world the vendor should really be able to list all possible IP addresses for the services, and doing so is likely the most robust way. But I'm a "there is no cloud, just other people's computers" person, so maybe I expect too much of vendors.) re 7. Privacy and 8. Security: Posession of intimate devices may cause embarassment. Posession of personal healthcare devices may open people up to attacks on their life. Imagine some dissident in Atlantis being assassinated on Princess Arielle's orders by way of targeting something on the dissident's dialysis machine, pacemaker, or whatever else. But vendors will still read this as "eh, people won't care if someone has my devices". And then 5 years later they get bought up and the new owner makes sex toys off the same codebase :) And lastly: "requirements for the devices to get access to network resources that may be critical to their continued safe operation." ... I guess this is more of a comment, but I certainly hope no hospital, metalworks, sewage works, or power plant ever depends on MUD functioning correctly to ensure *safe* operation. Hope this is useful input, -David From nobody Mon Dec 20 09:28:52 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5FF3A0E64 for ; Mon, 20 Dec 2021 09:28:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Bernardos via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bevolz@gmail.com, cjbc@it.uc3m.es, Carlos Bernardos Message-ID: <164002133013.18332.3787081230894265392@ietfa.amsl.com> Date: Mon, 20 Dec 2021 09:28:50 -0800 Archived-At: Subject: [Int-dir] Open review assignments in intdir X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 17:28:51 -0000 Hi all, The following reviewers have assignments: For telechat 2022-01-06 Reviewer LC end Draft Suresh Krishnan 2021-11-26 draft-ietf-httpbis-http2bis-06 Last calls: Reviewer LC end Draft Suresh Krishnan 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy-15 Suresh Krishnan 2021-11-26 draft-ietf-httpbis-http2bis-06 Charles Perkins 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates-14 Next in the reviewer rotation: David Lamparter David Lawrence Ted Lemon Benno Overeinder Basavaraj Patil Tommy Pauly Charles Perkins Carlos Pignataro Dave Thaler Pascal Thubert As a helpful reference for reviewers, please check the Directorates Guidelines available at: https://trac.ietf.org/trac/iesg/wiki/DirectoratesGuidelines Reviews must include the following boilerplate text in the comments sent: "I am an assigned INT directorate reviewer for . These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ ." For INT Area documents, reviewers must provide a recommendation if the document is ready to go to Last Call and therefore be forwarded to the IESG. For non-INT Area document, the reviewer must give a recommendation as to how the INT ADs are to complete the ballot on the document and the reason for that recommendation. See https://www.ietf.org/iesg/voting-procedures.html. Comments provided MUST be in the order of significance (i.e., those issues that are serious and must be fixed (i.e., DISCUSS level issues) MUST be first). While comments on minor issues (typos, etc.) are welcome, they should be last. A template review response might be: -8-<- BEGIN TEMPLATE -8-<- I am an assigned INT directorate reviewer for . These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . [INT Area documents] Based on my review, the document [IS, IS NOT] ready to go to IETF Last Call and therefore [CAN, CANNOT] be forwarded to the IESG [Non-INT Area documents] Based on my review, if I was on the IESG I would ballot this document as [YES, NO OBJECTION, DISCUSS, RETURN TO WG (ABSTAIN)]. I have the following DISCUSS/ABSTAIN level issues: The following are other issues I found with this document that SHOULD be corrected before publication: The following are minor issues (typos, misspelling, minor text improvements) with the document: -8-<- END TEMPLATE -8-<- From nobody Fri Dec 24 10:52:51 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1416E3A0EE8; Fri, 24 Dec 2021 10:52:36 -0800 (PST) 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=sandelman.ca 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 6ri6AoKCLdAl; Fri, 24 Dec 2021 10:52:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0FB3A0EE7; Fri, 24 Dec 2021 10:52:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 21E7D38B76; Fri, 24 Dec 2021 13:57:13 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MRRUMx0RdSLn; Fri, 24 Dec 2021 13:57:12 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D29CB38B75; Fri, 24 Dec 2021 13:57:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640372231; bh=svrc07piU3bgq7XXNAU3Y7VdmHkiljY4lXKjc5bOhvk=; h=From:To:Subject:In-Reply-To:References:Date:From; b=SuHAPohtCF1fZI9YwxllLu52nMkjSTvekXw4Eu72gmcwK/SK8jsD4HerLxThjHiMM WBgKa4ioWkhNqCuV+4C+O91pTz903n99K8wVo57Z9PMKGpbaOro5TaMfWXlW0bmhfY g2O9ryEngh00Qxjf3ZQqYxfOiwX1SXfAeulc5XqTEulHG83OGzdy46dy3QHvB/U1Vt yUbxEzr3Fgn6c2z3RqGRBUvr76RpBvE3Mq/qPt7YJ/kb4kgVGfSj0xKXFdSWr6ffL0 McKocW8z/8ayRIb0N8W6JySv941p9ot3vcIhlAAJUSpUVy8WOh70dkU0HTdOY5Li3K X0tyKXpDUVldA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A080F48F; Fri, 24 Dec 2021 13:52:26 -0500 (EST) From: Michael Richardson To: David Lamparter , int-dir@ietf.org, mud@ietf.org, draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, opsawg@ietf.org In-Reply-To: <163994413394.12070.6171048717943515773@ietfa.amsl.com> References: <163994413394.12070.6171048717943515773@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Int-dir] Intdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2021 18:52:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Normally, I like to reply with specific changes, but I haven't figured out what changes to make, and I also see that there are some XXX in my document that also reflect places I wanted to also make changes. So, please expect another reply with some specific text, once I've faulted enough pages back into the brain. David Lamparter via Datatracker wrote: > re. 3. Strategies to map names > - plain reverse lookups. > Some vendor working with cheapest available developers will sadly und= erstand > your list as "oh I just need to do my reverse maps /right/ and then i= t should > work." I'd say "explain in detail how this can fail." is not enough,= it might > need to be "explain in detail how this can fail even if the vendor tr= ies its > best". I think that I'd like to take another round trip with DNSOP then to make su= re that I've covered all the ways, and perhaps there is simply a document that= I can reference. > - the controller doing lookups, (potentially using the same caching r= esolver) > The MUD controller and the device using the same resolver is a neccss= ary > requirement, but not a sufficent one. Worse even, this is essentiall= y a > Time-Of-Check-Time-Of-Use security vulnerability. An attacker may be= able to > distinguish device-originated DNS lookups from controller-originated = lookups > and give the controller a much longer list of replies while still all= owing the > device to function normally to cover their tracks. It's fringe (if y= ou can > break DNS like that there's probably better things you can exploit), = but still. Yes, I agree that there is vulnerability here. Having the MUD controller do DNSSEC validation helps a lot, if the manufacturer can be bothered to sign with DNSSEC. Or using DoH, DoT... as either way the attacker now has to compromise the authoritative servers. I feel that there is a lot more to say here. > I haven't really put extensive thought into this, but the only > pedantically-correct solution to me seems to be to actually track the= exact > DNS responses that were given to the device. Yes, that certainly can be done, and in the home router (which is also the DNS server for the device), then it occurs quite naturally. Note that the goal of MUD is not perfect mapping, but rather a reduction in risk. As such I want to be very cautious about throwing away incremental improvements because they aren't perfect. > re 4.1. Use of IP address literals in-protocol > Nothing says the MUD file and device spec need to specify the target = in the > same way. It might actually be a good idea to give the device a DNS = name to > resolve, but just list all the IP addresses in the MUD file. The ven= dor should > absolutely be able to do that in some cases at least (i.e. no highly = dynamic > changes to the addresses.) Considering all else, this might even be = one of the > better approaches? This is already possible. I think that it will lead to too many operational problems. Do you think that the document should deal with this in a pro/con section? > On a sidenote, this also means it's wrong for the firewall to try to = validate > SNI names when the MUD file only lists IP addresses. Yes, that's true. As we go towards ESNI, I hope that firewalls won't try to do this, as I thi= nk that *validating* SNI is a mistake. Observing and auditing and logging if there are changes is a different situation though. I think it is reasonable for a MUD file to tell the MUD controller if the S= NI should be visible or not (see draft-ietf-opsawg-mud-tls...) > Technically the MUD file could also list a *different* DNS name that = is > guaranteed to return a superset of addresses that might be used by th= e device. > Whether this is a good idea I don't know. (Also note this conflicts = with > monitoring a device's DNS lookups to track the actual responses it re= ceived.) This definitely could be done. www-all.example.com, when www.example.com will return a geo-fenced address. > Ultimately though what I'd like to note here is that there's 2 differ= ent > objectives here. The device itself wants a useful subset of addresse= s to > contact. But the firewall needs the superset of anything the device = might > need to talk to. Agreed. I think that this paragraph is worth integrating into the document= somewhere. > re 5. DNS privacy and outsourcing versus MUD controllers > I honestly don't understand how any device vendor can reasonably enco= de some > specific DNS service into their device and expect it to work. If my = network, > whether it be home or corporate, has a policy for some specific DNS c= ache to > be used (e.g. on some firewall appliance), a MUD file isn't going to = punch a > hole into my policy for that. And this really zaps all the DoT & DoH= bits at > the same time. Yes, it sure happens. Go read the threads in ADD, particularly from Paul Vixie, about how Google devices will keep trying to talk to 8.8.8.8, even when given a local, fully functional, DNS server via DHCP, and even when 8.8.8.8 is blocked. > And with me being from Germany I can tell you we have ISPs that give = their > users a checkbox to block Cloudflare DoH on their service - not even = for > technical merits, just because it was a publicity sh*tstorm. (Neverm= ind the > fact that the ISPs may have their own ulterior motives.) Yes, go read Geoff Houston comments/presentation from the side meetings aft= er IETF112, at RIPE-83, and on the RIPE DNS-WG ML. The short of it is that DNS resolution doesn't make any money for the ISP, having it break costs th= em money and reputation, and so if they can outsource it to Google, from the ISP's point of view and for many users, it's a win-win. From=20a MUD controller point of view, it's just fine if the home router ta= lks to some outsourced DNS server rather, as long as the queries from the device get cached in the router. This is exactly how openwrt running dnsmasq work= today. > 6.5. seems a no-brainer, maybe even too weak of a conclusion. Device= s /really/ > should use the DNS they get told by the network. Yeah. Are you asking for strong language here? > 6.1. is the MUD file a protocol too? It's not clear from the text. > (I do also disagree on the conclusion, in my naive world the vendor s= hould > really be able to list all possible IP addresses for the services, an= d doing > so is likely the most robust way. But I'm a "there is no cloud, just= other > people's computers" person, so maybe I expect too much of vendors.) 6.1 is not about MUD exactly, but rather other protocols. Section 4.1 talks about this problem. In my experience trying to fashion MUD files for things like printers, it's endemnic in the update protocol. > re 7. Privacy and 8. Security: >> Posession of intimate devices may cause embarassment. Posession of = personal >> healthcare devices may open people up to attacks on their life. Ima= gine some >> dissident in Atlantis being assassinated on Princess Arielle's order= s by way >> of targeting something on the dissident's dialysis machine, pacemake= r, or >> whatever else. May I use your Atlantis/Little Mermaid example? :-) I am of the wrong age to really have experienced that film (too old for me, and it's too ancient to interest my kid... now teenager). I don't remember there being dialysis machines in Atlantica. > But vendors will still read this as "eh, people won't care if someone= has my > devices". And then 5 years later they get bought up and the new owne= r makes > sex toys off the same codebase :) > And lastly: "requirements for the devices to get access to network re= sources > that may be critical to their continued safe operation." ... I guess = this is > more of a comment, but I certainly hope no hospital, metalworks, sewa= ge works, > or power plant ever depends on MUD functioning correctly to ensure *s= afe* > operation. Frankly, I hope that they do use MUD. That's the whole point here. If it's not good enough for them, then why are we even bothering? They are currently frantically trying to put ACLs in place to restrict acce= ss by devices to the network. The amount of call-home-or-it-does-not-work is quite amazing. Yes, most of here in the IETF think that IoT should be devices talking to other devices, not device->cloud->device, but firewalls and NAT44 have gotten in the way. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHGFuoACgkQgItw+93Q 3WU+Cwf/ZHC27Ktr0wtzy1Fkuixizc6FE6cjcYQsmqPD2Gi0bZ2YNDWYgtvdxfaT h6D4/4jcV0+ri+log9O/CdXgbKbEJf1bIjdFnDuCYwyaM0NLgSQ0D1oKUkluhfze cdu/wvJLUulWo0aHHp9twjUjpXzMzzJK5GlSk7bZY+6ca7N4nJl0oB/RnE1NoUBJ LYkvHcB8apzGOKlg6TJK5Qvra729MzAQP9ipiNY0MRbIsq/sXhw2fFqqupi6aW2g lvpa6chla3Vp5BNBX5DkVKgee1mAmxjGsewY7IabLB0nTVQpjQd/WU00ayoZI2Q7 TEl2CZ3xd6IfqYBcjfhpgkcpI17XIw== =isIr -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Dec 25 03:09:25 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35F73A0D43; Sat, 25 Dec 2021 03:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8oYC6EKqtu2; Sat, 25 Dec 2021 03:09:18 -0800 (PST) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 0E1203A0D42; Sat, 25 Dec 2021 03:09:15 -0800 (PST) Received: from equinox by eidolon.nox.tf with local (Exim 4.94.2) (envelope-from ) id 1n14vF-0092VB-6h; Sat, 25 Dec 2021 12:09:09 +0100 Date: Sat, 25 Dec 2021 12:09:09 +0100 From: David Lamparter To: Michael Richardson Cc: int-dir@ietf.org, mud@ietf.org, draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, opsawg@ietf.org Message-ID: References: <163994413394.12070.6171048717943515773@ietfa.amsl.com> <14215.1640371946@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14215.1640371946@localhost> Archived-At: Subject: Re: [Int-dir] Intdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2021 11:09:24 -0000 On Fri, Dec 24, 2021 at 01:52:26PM -0500, Michael Richardson wrote: > Normally, I like to reply with specific changes, but I haven't figured out > what changes to make, and I also see that there are some XXX in my document > that also reflect places I wanted to also make changes. > So, please expect another reply with some specific text, once I've faulted > enough pages back into the brain. I'm noticing I communicated some of my thoughts quite poorly, probably in part because I was somewhat unsure on distinguishing "comments" from "review". Apologies for that, I'll note to put a bit more time into clearer communication on future reviews. I also have really taken a wrong turn in basing some of my feedback on thinking the names looked up by the device would match ACL entries in the MUD file, particularly this first item: > > - the controller doing lookups, (potentially using the same caching resolver) > > > The MUD controller and the device using the same resolver is a neccssary > > requirement, but not a sufficent one. Worse even, this is essentially a > > Time-Of-Check-Time-Of-Use security vulnerability. An attacker may be able to > > distinguish device-originated DNS lookups from controller-originated lookups > > and give the controller a much longer list of replies while still allowing the > > device to function normally to cover their tracks. It's fringe (if you can > > break DNS like that there's probably better things you can exploit), but still. > > Yes, I agree that there is vulnerability here. > > Having the MUD controller do DNSSEC validation helps a lot, if the > manufacturer can be bothered to sign with DNSSEC. > Or using DoH, DoT... as either way the attacker now has to compromise the > authoritative servers. In retrospect, I really regret bringing this perspective to the table. It only makes sense from a "100% match/constraint" perspective. But with a make-before-break approach, the ACL being wider than the actual usage by the MUD device is intentional. Turning my paragraph on its head, it might rather be prudent to repeat (for the benefit of network operators) that a MUD file can be arbitrarily lax on its constraints. Attacks on DNS can't widen it further than plain manufacturer indifference to putting work into a good set of ACLs. But after spending a bit more thought on this, I actually think I have a good piece of proper "review" suggestion: I think it would be immensely useful to add/describe the perspective of what happens when addresses associated with a service are 1. added, 2. removed, or 3. fully replaced. All the DNS caching and "perspective" effects come down to the same differences, but they're corner cases to ops. Moving services around is core ops. [-- continued below at anchor "A"] > I feel that there is a lot more to say here. And it really applies generally to using DNS names in ACLs. I'm unaware of any other document that went this direction, is there any? RFC 8520 might've skipped over a seemingly innocuous but on closer look quite nontrivial chunk of considerations here. > > I haven't really put extensive thought into this, but the only > > pedantically-correct solution to me seems to be to actually track the exact > > DNS responses that were given to the device. > > Yes, that certainly can be done, and in the home router (which is also the > DNS server for the device), then it occurs quite naturally. [-- anchor "A", continuing on add/remove/replace] Looking at these 3 temporal changes, the takeaway I've evolved to at this point is that there are 2 overall patterns to get to "full correctness": - either the MUD controller shares the exact DNS->IP view that the MUD device has, ideally down to individual DNS lookup results. BUT: this implies the names listed in the MUD file must exactly match what the device looks up - and that's neither provided nor intended by 8520. Which really just renders this moot for further consideration. (It also requires controller and device to use the same DNS infrastructure.) - or the entire thing instead moves to a make-before-break approach. The names in the MUD file receive address additions before the device sees them, and deletions after they expire out of device visibility. BUT: this implies the names listed cannot match what the device looks up/uses, and needs significant extra care by the device manufacturer. The second item here I had kindof headed towards in my original review when I mentioned using separate names, but I'll freely admit I hadn't thought this to the end of being good ol' make-before-break. Both approaches would solve the 3 "temporal operations", though in almost antithetical ways: construct a kind of atomicity to the changes vs. split the operation into 2 or 3 stages. [-- anchor "B", the following 3 paragraphs are redunant, left them here just for clarity/explicitness] Ultimately, again, this is really an issue of diametrically opposed function of the name lookups. Not sure which terms to use - "necessary vs. sufficient", "additive vs. subtractive", "permissive vs. restrictive" - but it boils down to: The MUD device starts with an empty set of endpoints and uses DNS to put a few addresses into the set so it can pick something to talk to. If the set of addresses is *smaller* than the set of addresses that provide the necessary service/function for the device to operate, that's perfectly fine. The MUD controller starts with allowing the unrestricted set of the entire internet (equivalent to no MUD file too) and is using DNS to narrow down this set. If the set of addresses is *larger* than the set id above, that's perfectly fine. [-- end redundant] > Note that the goal of MUD is not perfect mapping, but rather a reduction in > risk. As such I want to be very cautious about throwing away incremental > improvements because they aren't perfect. Fully agree. Lacking sufficient context and knowledge, I unfortunately have no clue what would lead to the best actual realized improvements. > > re 4.1. Use of IP address literals in-protocol > > > Nothing says the MUD file and device spec need to specify the target in the > > same way. It might actually be a good idea to give the device a DNS name to > > resolve, but just list all the IP addresses in the MUD file. The vendor should > > absolutely be able to do that in some cases at least (i.e. no highly dynamic > > changes to the addresses.) Considering all else, this might even be one of the > > better approaches? > > This is already possible. > I think that it will lead to too many operational problems. > Do you think that the document should deal with this in a pro/con section? This paragraph of mine really came about from me thinking about the make-before-break consideration above, though I hadn't arrived at that myself just yet. I suggested listing all the IP addresses only because I was stuck with this "additive" use of DNS and took listing addresses as "subtractive" converse. The real point is to distinguish that converse approach, not the distinction between use of DNS and addresses. > > On a sidenote, this also means it's wrong for the firewall to try to validate > > SNI names when the MUD file only lists IP addresses. > > Yes, that's true. > As we go towards ESNI, I hope that firewalls won't try to do this, as I think > that *validating* SNI is a mistake. Observing and auditing and logging if > there are changes is a different situation though. > I think it is reasonable for a MUD file to tell the MUD controller if the SNI > should be visible or not (see draft-ietf-opsawg-mud-tls...) Let me reword the review item: for section 1, SNI considerations, I think you should make clear the MUD file is making no commitment at all that the names listed in the ACLs would match what the device ends up negotiating a TLS connection to. The DNS names in a MUD file are just indirections to listing IP addresses. So looking at SNI names is wrong even when it's possible. > > Technically the MUD file could also list a *different* DNS name that is > > guaranteed to return a superset of addresses that might be used by the device. > > Whether this is a good idea I don't know. (Also note this conflicts with > > monitoring a device's DNS lookups to track the actual responses it received.) > > This definitely could be done. > www-all.example.com, when www.example.com will return a geo-fenced address. Exactly this. > > Ultimately though what I'd like to note here is that there's 2 different > > objectives here. The device itself wants a useful subset of addresses to > > contact. But the firewall needs the superset of anything the device might > > need to talk to. > > Agreed. I think that this paragraph is worth integrating into the document somewhere. [this is what the earlier 3 paragraphs at anchor "B" are redundant with.] [...some paragraphs cut...] > > 6.5. seems a no-brainer, maybe even too weak of a conclusion. Devices /really/ > > should use the DNS they get told by the network. > > Yeah. Are you asking for strong language here? Yes, though to clarify, I should've inserted a "first" there. Nothing wrong with a fallback, if it's implemented correctly. (And if a particular network requires DNS lookups from devices to pass through its DNS service to enforce some security purpose, it needs to be blocking other DNS anyway.) > > 6.1. is the MUD file a protocol too? It's not clear from the text. > > > (I do also disagree on the conclusion, in my naive world the vendor should > > really be able to list all possible IP addresses for the services, and doing > > so is likely the most robust way. But I'm a "there is no cloud, just other > > people's computers" person, so maybe I expect too much of vendors.) > > 6.1 is not about MUD exactly, but rather other protocols. > Section 4.1 talks about this problem. In my experience trying to fashion > MUD files for things like printers, it's endemnic in the update protocol. Ok - this absolutely needs wording clarification, because your current wording can be read as recommendations to either "always use DNS names on the device and MUD file", but also "always use DNS names, but this is no statement about the MUD file". > > re 7. Privacy and 8. Security: > > >> Posession of intimate devices may cause embarassment. Posession of personal > >> healthcare devices may open people up to attacks on their life. Imagine some > >> dissident in Atlantis being assassinated on Princess Arielle's orders by way > >> of targeting something on the dissident's dialysis machine, pacemaker, or > >> whatever else. > > May I use your Atlantis/Little Mermaid example? :-) Sure :D > I am of the wrong age to really have experienced that film (too old for me, > and it's too ancient to interest my kid... now teenager). I don't remember > there being dialysis machines in Atlantica. Honestly I just didn't want to name any particular oppressive regime for obvious political reasons. I thought about fictional continents and only associated to the movie from there... > > And lastly: "requirements for the devices to get access to network resources > > that may be critical to their continued safe operation." ... I guess this is > > more of a comment, but I certainly hope no hospital, metalworks, sewage works, > > or power plant ever depends on MUD functioning correctly to ensure *safe* > > operation. > > Frankly, I hope that they do use MUD. Oh they absolutely should. I was trying to say they can't rely on it for functional safety. In most fields, safety regulations and certifications will already require safe operation to be a property inherent to the device as much as possible. A MUD file is an extra defensive layer, but if it fails open, that's no excuse for a device to die in a "bad" way (e.g. because background internet traffic like SSH portscans tripped/deadlocked something in its embedded firmware, and the deadlock causes e.g. raw sewage to get into the drinking water supply.) Cheers and Happy Holidays, -David