From nobody Mon Sep 7 18:42:17 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127A23A0DF7; Mon, 7 Sep 2020 18:42:16 -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 eiBQol6QJ1vS; Mon, 7 Sep 2020 18:42:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43383A0DEF; Mon, 7 Sep 2020 18:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 054F0389D0; Mon, 7 Sep 2020 21:20:44 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id In9boYpldMf4; Mon, 7 Sep 2020 21:20:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9771F389CD; Mon, 7 Sep 2020 21:20:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C603BA8; Mon, 7 Sep 2020 21:41:50 -0400 (EDT) From: Michael Richardson To: mud@ietf.org, iot-onboarding@ietf.org Reply-To: mud@ietf.org X-Attribution: mcr 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: [Mud] thinking again about an IoT security WG X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 01:42:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Last year, I wrote: https://github.com/mcr/iotwg-charter/blob/master/iotwg-charter.md which I also attach below. Pull requests and edits would be most welcome. Rip it to shreds, please. It was discussed in a thread: https://mailarchive.ietf.org/arch/msg/iot-onboarding/CWJfPD3mSUz_chZR8= FmWuKGVaEk/ The main criticism involved attempts to boil oceans. I believe that the effort is manageable, because it simply involves a number of small steps forward. We just need to coordinate some of the steps. Meanwhile, I have received a number of encouraging remarks. I have CC'ed mud@ietf.org, and iot-onboarding, but let's just use mud@ietf.org. The Reply-To I put in will likely get stripped by the IETF mailman. I would like to propose an online virtual discussion at the end of September to discuss next steps. Whether we should call this a virtual non-WG formi= ng BOF is a discussion that I think we should have, and perhaps some ADs will = comment. =2D-- # Charter for Working Group The words "Internet of Things" or IoT have come to mean anything and everything to a wide group of technology players. The IETF has been worki= ng on a wide variety of protocols for use by machine to machine communication. This include CoAP, CBOR, 6TISCH, ROLL, SUIT, NETCONF SZTP, T2TRG, ANIMA's B= RSKI onboarding protocol, and most recently RFC8520, the Manufacturer Usage Description. The IETF has tried to focus on categories of what limited things can do, and this has resulted in a number of useful documents from the Light-Weight Implementation Guide (LWIG). RFC7228 is a key product, having provided terminology and scaling understanding to the entire industry. All of this has been about scaling the Internet technologies to small devic= es and constrained networks. In aggregate, these devices on small networks present a significant operational risk to the Internet as a whole, and even to individual Enterprise, simply due to their numbers, and lack of opportunity for regular human supervision. IoT devices already exist today in vast numbers. Most devices that people are personally familiar with are in the BlueTooth Connected devices, or Web-Connected devices that use WiFi to reach servers on the Internet ("t= he Cloud"). Increasingly, the IETF view of machine to machine communications are colini= zing new greenfield situations. The IETF notion of autonomous networks of devic= es is still a minority view compared to the market IoT industry of cloud-only connected devices, but the transition is occuring. RFC8520 was created to bridge the gap between devices wholly controlled by a local operator (such as Enterprise IT), and devices which can not assume any infrastructure at all, and must rely entirely on cloud communications f= or command and control. This working group concerns itself with Operational Security of IoT systems. This includes: * factory provisioning of devices * onboarding of devices * access control of devices to network resources * administrative control of devices * asset management of devices, as it pertains to software/firmware versio= ns * isolation/quarantine of devices * remediation of broken devices * end of life management of devices The WG is chartered explicitely to work on MUD (RFC8520) and extensions to it within the point ("access control of devices...") The WG is chartered to work on onboarding protocols, specifically including derivaties of BRSKI (RFC-tbd), but not limited to just that protocol.=20=20 The WG is not expected to pick a winner, and is encouraged to work on a multitude of use-case specific protocols: better to get one use case right, than to be too-complex jack of all trades. The WG is expected to articulate clear applicability statements for each protocol. The WG is expected to produce concise Roadmap documents that explain how a variety of IETF (and other) protocols can work together to satisfy the Operational needs of specific IoT areas.=20 These roadmap documents needn=E2=80=99t result in RFCs, the WG will decide = with advice from the responsible Area Director. Neither the WG nor the IETF has exclusivity here, and an ideal document wou= ld be one that the WG helps to start, but a specific industry alliance becomes the lead editor for. There will be coordination with many other WGs beyond the list above, and this WG may accept applicability statement work from other WGs about specif= ic ways to deploy their protocols. The WG will operate through a series of virtual interim meetings. This is driven by a need to interact regularly with other industry grouops, and due to the variety of topics which will not always be able to get quorum as= a committee of the whole. {unusual, maybe not charter appropriate, but rather saag-like} During in-person meetings, the WG will deal with typical status and document progress issues during one hour (or less) of the time, and during another hour, will be open to slideware presentations and tutorials on current IETF or other-SDO IoT efforts. The goal of these presentations is to quick= ly communicate current IoT *systems* state to the rest of the IETF.=20=20 It is acknowledged that part of the value is in YouTube content, and some content should be done at IAB tech plenaries rather than at the WG. The initial set of work items is included below as milestones, which only require AD approval. Milestones * adopt the constrained-voucher/constrained-BRSKI work from ANIMA. * adopt the dtsecurity-zero-touch work from 6tisch, which can not finish be= fore a LAKE finishes. * create a list of a series of MUD extensions, and revise this milestone * adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possibly a= version of EAP-NOOB), that can be used at the retail level. * negotiate with EMU WG on how to proceed with TEAP-BRSKI, and revise this = milestone. * adopt a cloud-driven onboarding mechanism that can be used in completely offline situations without requiring renewals (perhaps revising RFC8366). =2D-=20 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+93Q3WUFAl9W4V4ACgkQgItw+93Q 3WUW7ggAtJapZRhYVwSH4S7J+gGY8xZ2mPDW+75CyeJuDZ5NuItKUyeL0iAoFAqD uIR+cbShas3MYBTD8pux65SRk2ObIyDr7xtKH9OY1mL/xDxdRwI7aBqYIVehMdWu SKQztErwvRKXeGl61PTUal/CKkenf87CyujYNxswXGaFgouivegvNMPWWV7dBBiC XlteqLd0BHcIqhg+i2D1OH+A1ArAjfmPCM321LJNDiYUkYtV4EYRgzEkpw7nSqr1 dy7cd7xZrOz7CSe9KnLAQqSkWTgQquCmW05PTZPx5jhxGrPp3nnvF1QNZSBKTiil 1G1tniXnRgwIggTotQh3/ARf6/bIsw== =mKMY -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 17 05:17:42 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA3A3A090C; Thu, 17 Sep 2020 05:17:41 -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 nsN1Egz3TaQ3; Thu, 17 Sep 2020 05:17:39 -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 CE2EA3A08DC; Thu, 17 Sep 2020 05:17:38 -0700 (PDT) Received: from lhreml731-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CBA74A21DBA6A1E29BA3; Thu, 17 Sep 2020 13:17:36 +0100 (IST) Received: from lhreml731-chm.china.huawei.com (10.201.108.82) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 17 Sep 2020 13:17:36 +0100 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 17 Sep 2020 13:17:36 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.93]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Thu, 17 Sep 2020 20:17:32 +0800 From: Qin Wu To: Michael Richardson CC: "iot-onboarding@ietf.org" , "mud@ietf.org" Thread-Topic: [Iot-onboarding] thinking again about an IoT security WG Thread-Index: AdaMvkQMZyBNVAUjRnKZo4dDsDXtuw== Date: Thu, 17 Sep 2020 12:17:32 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Mud] [Iot-onboarding] thinking again about an IoT security WG X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 12:17:41 -0000 TWljaGFlbDoNCkludGVyZXN0aW5nIHdvcmssIEkgZmVlbCB0aGlzIGlzIGEgY3Jvc3MgYXJlYSB0 b3BpYywgaXQgcmVxdWlyZXMgYSBsb3Qgb2YgY29vcmRpbmF0aW9uIHdpdGggU1VJVCwgRU1VLCBU MlRSRyBvdGhlciBXR3Mgd2l0aGluIElFVEYgYW5kIGluZHVzdHJ5IGFsbGlhbmNlcyBpbiB0aGUg b3V0c2lkZSBvZiBJRVRGLg0Kb25lIHF1aWNrIGNvbW1lbnQgdG8gY2hhcnRlciBwcm9wb3NhbCBp cyByZWxhdGVkIHRvIGFkbWluaXN0cmF0aW9uIGNvbnRyb2wgb2YgZGV2aWNlLA0KaXQgaXMgbm90 IGNsZWFyIGhvdyBkbyB5b3UgZGVmaW5lIGFkbWluaXN0cmF0aW9uIGNvbnRyb2wgZm9yIElvVCBk ZXZpY2U/DQoNCi1RaW4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSW90 LW9uYm9hcmRpbmcgW21haWx0bzppb3Qtb25ib2FyZGluZy1ib3VuY2VzQGlldGYub3JnXSBPbiAN Cj4gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbg0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1i ZXIgOCwgMjAyMCA5OjQyIEFNDQo+IFRvOiBtdWRAaWV0Zi5vcmc7IGlvdC1vbmJvYXJkaW5nQGll dGYub3JnDQo+IFN1YmplY3Q6IFtJb3Qtb25ib2FyZGluZ10gdGhpbmtpbmcgYWdhaW4gYWJvdXQg YW4gSW9UIHNlY3VyaXR5IFdHDQo+IA0KPiANCj4gTGFzdCB5ZWFyLCBJIHdyb3RlOg0KPiAgICAg IGh0dHBzOi8vZ2l0aHViLmNvbS9tY3IvaW90d2ctY2hhcnRlci9ibG9iL21hc3Rlci9pb3R3Zy1j aGFydGVyLm1kDQo+IHdoaWNoIEkgYWxzbyBhdHRhY2ggYmVsb3cuICBQdWxsIHJlcXVlc3RzIGFu ZCBlZGl0cyB3b3VsZCBiZSBtb3N0IHdlbGNvbWUuDQo+IFJpcCBpdCB0byBzaHJlZHMsIHBsZWFz ZS4NCj4gDQo+IEl0IHdhcyBkaXNjdXNzZWQgaW4gYSB0aHJlYWQ6DQo+IA0KPiBodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lvdC1vbmJvYXJkaW5nL0NXSmZQRDNtU1V6X2No WlINCj4gOEZtV3VLR1ZhRWsvDQo+IA0KPiBUaGUgbWFpbiBjcml0aWNpc20gaW52b2x2ZWQgYXR0 ZW1wdHMgdG8gYm9pbCBvY2VhbnMuDQo+IEkgYmVsaWV2ZSB0aGF0IHRoZSBlZmZvcnQgaXMgbWFu YWdlYWJsZSwgYmVjYXVzZSBpdCBzaW1wbHkgaW52b2x2ZXMgYSANCj4gbnVtYmVyIG9mIHNtYWxs IHN0ZXBzIGZvcndhcmQuICBXZSBqdXN0IG5lZWQgdG8gY29vcmRpbmF0ZSBzb21lIG9mIHRoZSBz dGVwcy4NCj4gDQo+IE1lYW53aGlsZSwgSSBoYXZlIHJlY2VpdmVkIGEgbnVtYmVyIG9mIGVuY291 cmFnaW5nIHJlbWFya3MuDQo+IA0KPiBJIGhhdmUgQ0MnZWQgbXVkQGlldGYub3JnLCBhbmQgaW90 LW9uYm9hcmRpbmcsIGJ1dCBsZXQncyBqdXN0IHVzZSANCj4gbXVkQGlldGYub3JnLiAgVGhlIFJl cGx5LVRvIEkgcHV0IGluIHdpbGwgbGlrZWx5IGdldCBzdHJpcHBlZCBieSB0aGUgDQo+IElFVEYg bWFpbG1hbi4NCj4gDQo+IEkgd291bGQgbGlrZSB0byBwcm9wb3NlIGFuIG9ubGluZSB2aXJ0dWFs IGRpc2N1c3Npb24gYXQgdGhlIGVuZCBvZiBTZXB0ZW1iZXINCj4gdG8gZGlzY3VzcyBuZXh0IHN0 ZXBzLiAgIFdoZXRoZXIgd2Ugc2hvdWxkIGNhbGwgdGhpcyBhIHZpcnR1YWwgbm9uLVdHDQo+IGZv cm1pbmcNCj4gQk9GIGlzIGEgZGlzY3Vzc2lvbiB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUs IGFuZCBwZXJoYXBzIHNvbWUgQURzIA0KPiB3aWxsIGNvbW1lbnQuDQo+IA0KPiAtLS0NCj4gDQo+ IA0KPiAjIENoYXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXANCj4gDQo+IFRoZSB3b3JkcyAiSW50ZXJu ZXQgb2YgVGhpbmdzIiBvciBJb1QgaGF2ZSBjb21lIHRvIG1lYW4gYW55dGhpbmcgYW5kIA0KPiBl dmVyeXRoaW5nICB0byBhIHdpZGUgZ3JvdXAgb2YgdGVjaG5vbG9neSBwbGF5ZXJzLiAgVGhlIElF VEYgaGFzIGJlZW4gDQo+IHdvcmtpbmcgb24gYSB3aWRlIHZhcmlldHkgb2YgcHJvdG9jb2xzIGZv ciB1c2UgYnkgbWFjaGluZSB0byBtYWNoaW5lIA0KPiBjb21tdW5pY2F0aW9uLg0KPiBUaGlzIGlu Y2x1ZGUgQ29BUCwgQ0JPUiwgNlRJU0NILCBST0xMLCBTVUlULCBORVRDT05GIFNaVFAsIFQyVFJH LCANCj4gQU5JTUEncyBCUlNLSSBvbmJvYXJkaW5nIHByb3RvY29sLCBhbmQgbW9zdCByZWNlbnRs eSBSRkM4NTIwLCB0aGUgDQo+IE1hbnVmYWN0dXJlciBVc2FnZSBEZXNjcmlwdGlvbi4NCj4gDQo+ IFRoZSBJRVRGIGhhcyB0cmllZCB0byBmb2N1cyBvbiBjYXRlZ29yaWVzIG9mIHdoYXQgbGltaXRl ZCB0aGluZ3MgY2FuIA0KPiBkbywgYW5kIHRoaXMgaGFzIHJlc3VsdGVkIGluIGEgbnVtYmVyIG9m IHVzZWZ1bCBkb2N1bWVudHMgZnJvbSB0aGUgDQo+IExpZ2h0LVdlaWdodCBJbXBsZW1lbnRhdGlv biBHdWlkZSAoTFdJRykuICBSRkM3MjI4IGlzIGEga2V5IHByb2R1Y3QsIA0KPiBoYXZpbmcgcHJv dmlkZWQgdGVybWlub2xvZ3kgYW5kIHNjYWxpbmcgdW5kZXJzdGFuZGluZyB0byB0aGUgZW50aXJl IGluZHVzdHJ5Lg0KPiBBbGwgb2YgdGhpcyBoYXMgYmVlbiBhYm91dCBzY2FsaW5nIHRoZSBJbnRl cm5ldCB0ZWNobm9sb2dpZXMgdG8gc21hbGwgDQo+IGRldmljZXMgYW5kIGNvbnN0cmFpbmVkIG5l dHdvcmtzLiAgSW4gYWdncmVnYXRlLCB0aGVzZSBkZXZpY2VzIG9uIA0KPiBzbWFsbCBuZXR3b3Jr cyBwcmVzZW50IGEgc2lnbmlmaWNhbnQgb3BlcmF0aW9uYWwgcmlzayB0byB0aGUgSW50ZXJuZXQg DQo+IGFzIGEgd2hvbGUsIGFuZCBldmVuIHRvIGluZGl2aWR1YWwgRW50ZXJwcmlzZSwgc2ltcGx5 IGR1ZSB0byB0aGVpciANCj4gbnVtYmVycywgYW5kIGxhY2sgb2Ygb3Bwb3J0dW5pdHkgZm9yIHJl Z3VsYXIgaHVtYW4gc3VwZXJ2aXNpb24uDQo+IA0KPiBJb1QgZGV2aWNlcyBhbHJlYWR5IGV4aXN0 IHRvZGF5IGluIHZhc3QgbnVtYmVycy4gIE1vc3QgZGV2aWNlcyB0aGF0IA0KPiBwZW9wbGUgYXJl IHBlcnNvbmFsbHkgZmFtaWxpYXIgd2l0aCBhcmUgaW4gdGhlIEJsdWVUb290aCBDb25uZWN0ZWQg DQo+IGRldmljZXMsIG9yIFdlYi1Db25uZWN0ZWQgZGV2aWNlcyB0aGF0IHVzZSBXaUZpIHRvIHJl YWNoIHNlcnZlcnMgb24gDQo+IHRoZSBJbnRlcm5ldCAoInRoZSBDbG91ZCIpLg0KPiBJbmNyZWFz aW5nbHksIHRoZSBJRVRGIHZpZXcgb2YgbWFjaGluZSB0byBtYWNoaW5lIGNvbW11bmljYXRpb25z IGFyZSANCj4gY29saW5pemluZyBuZXcgZ3JlZW5maWVsZCBzaXR1YXRpb25zLiAgVGhlIElFVEYg bm90aW9uIG9mIGF1dG9ub21vdXMgDQo+IG5ldHdvcmtzIG9mIGRldmljZXMgaXMgc3RpbGwgYSBt aW5vcml0eSB2aWV3IGNvbXBhcmVkIHRvIHRoZSBtYXJrZXQgDQo+IElvVCBpbmR1c3RyeSBvZiBj bG91ZC1vbmx5IGNvbm5lY3RlZCBkZXZpY2VzLCBidXQgdGhlIHRyYW5zaXRpb24gaXMgb2NjdXJp bmcuDQo+IA0KPiBSRkM4NTIwIHdhcyBjcmVhdGVkIHRvIGJyaWRnZSB0aGUgZ2FwIGJldHdlZW4g ZGV2aWNlcyB3aG9sbHkgDQo+IGNvbnRyb2xsZWQgYnkgYSBsb2NhbCBvcGVyYXRvciAoc3VjaCBh cyBFbnRlcnByaXNlIElUKSwgYW5kIGRldmljZXMgDQo+IHdoaWNoIGNhbiBub3QgYXNzdW1lIGFu eSBpbmZyYXN0cnVjdHVyZSBhdCBhbGwsIGFuZCBtdXN0IHJlbHkgZW50aXJlbHkgDQo+IG9uIGNs b3VkIGNvbW11bmljYXRpb25zIGZvciBjb21tYW5kIGFuZCBjb250cm9sLg0KPiANCj4gVGhpcyB3 b3JraW5nIGdyb3VwIGNvbmNlcm5zIGl0c2VsZiB3aXRoIE9wZXJhdGlvbmFsIFNlY3VyaXR5IG9m IElvVCBzeXN0ZW1zLg0KPiANCj4gVGhpcyBpbmNsdWRlczoNCj4gICAqIGZhY3RvcnkgcHJvdmlz aW9uaW5nIG9mIGRldmljZXMNCj4gICAqIG9uYm9hcmRpbmcgb2YgZGV2aWNlcw0KPiAgICogYWNj ZXNzIGNvbnRyb2wgb2YgZGV2aWNlcyB0byBuZXR3b3JrIHJlc291cmNlcw0KPiAgICogYWRtaW5p c3RyYXRpdmUgY29udHJvbCBvZiBkZXZpY2VzDQo+ICAgKiBhc3NldCBtYW5hZ2VtZW50IG9mIGRl dmljZXMsIGFzIGl0IHBlcnRhaW5zIHRvIHNvZnR3YXJlL2Zpcm13YXJlIA0KPiB2ZXJzaW9ucw0K PiAgICogaXNvbGF0aW9uL3F1YXJhbnRpbmUgb2YgZGV2aWNlcw0KPiAgICogcmVtZWRpYXRpb24g b2YgYnJva2VuIGRldmljZXMNCj4gICAqIGVuZCBvZiBsaWZlIG1hbmFnZW1lbnQgb2YgZGV2aWNl cw0KPiANCj4gVGhlIFdHIGlzIGNoYXJ0ZXJlZCBleHBsaWNpdGVseSB0byB3b3JrIG9uIE1VRCAo UkZDODUyMCkgYW5kIA0KPiBleHRlbnNpb25zIHRvIGl0IHdpdGhpbiB0aGUgcG9pbnQgKCJhY2Nl c3MgY29udHJvbCBvZiBkZXZpY2VzLi4uIikNCj4gDQo+IFRoZSBXRyBpcyBjaGFydGVyZWQgdG8g d29yayBvbiBvbmJvYXJkaW5nIHByb3RvY29scywgc3BlY2lmaWNhbGx5IA0KPiBpbmNsdWRpbmcg ZGVyaXZhdGllcyBvZiBCUlNLSSAoUkZDLXRiZCksIGJ1dCBub3QgbGltaXRlZCB0byBqdXN0IHRo YXQgDQo+IHByb3RvY29sLg0KPiBUaGUgV0cgaXMgbm90IGV4cGVjdGVkIHRvIHBpY2sgYSB3aW5u ZXIsIGFuZCBpcyBlbmNvdXJhZ2VkIHRvIHdvcmsgb24gDQo+IGEgbXVsdGl0dWRlIG9mIHVzZS1j YXNlIHNwZWNpZmljIHByb3RvY29sczogYmV0dGVyIHRvIGdldCBvbmUgdXNlIGNhc2UgDQo+IHJp Z2h0LCB0aGFuIHRvIGJlIHRvby1jb21wbGV4IGphY2sgb2YgYWxsIHRyYWRlcy4NCj4gDQo+IFRo ZSBXRyBpcyBleHBlY3RlZCB0byBhcnRpY3VsYXRlIGNsZWFyIGFwcGxpY2FiaWxpdHkgc3RhdGVt ZW50cyBmb3IgDQo+IGVhY2ggcHJvdG9jb2wuICBUaGUgV0cgaXMgZXhwZWN0ZWQgdG8gcHJvZHVj ZSBjb25jaXNlIFJvYWRtYXAgDQo+IGRvY3VtZW50cyB0aGF0IGV4cGxhaW4gaG93IGEgdmFyaWV0 eSBvZiBJRVRGIChhbmQgb3RoZXIpIHByb3RvY29scyBjYW4gDQo+IHdvcmsgdG9nZXRoZXIgdG8g c2F0aXNmeSB0aGUgT3BlcmF0aW9uYWwgbmVlZHMgb2Ygc3BlY2lmaWMgSW9UIGFyZWFzLg0KPiBU aGVzZSByb2FkbWFwIGRvY3VtZW50cyBuZWVkbuKAmXQgcmVzdWx0IGluIFJGQ3MsIHRoZSBXRyB3 aWxsIGRlY2lkZSANCj4gd2l0aCBhZHZpY2UgZnJvbSB0aGUgcmVzcG9uc2libGUgQXJlYSBEaXJl Y3Rvci4NCj4gDQo+IE5laXRoZXIgdGhlIFdHIG5vciB0aGUgSUVURiBoYXMgZXhjbHVzaXZpdHkg aGVyZSwgYW5kIGFuIGlkZWFsIA0KPiBkb2N1bWVudCB3b3VsZCBiZSBvbmUgdGhhdCB0aGUgV0cg aGVscHMgdG8gc3RhcnQsIGJ1dCBhIHNwZWNpZmljIA0KPiBpbmR1c3RyeSBhbGxpYW5jZSBiZWNv bWVzIHRoZSBsZWFkIGVkaXRvciBmb3IuDQo+IA0KPiBUaGVyZSB3aWxsIGJlIGNvb3JkaW5hdGlv biB3aXRoIG1hbnkgb3RoZXIgV0dzIGJleW9uZCB0aGUgbGlzdCBhYm92ZSwgDQo+IGFuZCB0aGlz IFdHIG1heSBhY2NlcHQgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgd29yayBmcm9tIG90aGVyIFdH cyANCj4gYWJvdXQgc3BlY2lmaWMgd2F5cyB0byBkZXBsb3kgdGhlaXIgcHJvdG9jb2xzLg0KPiAN Cj4gVGhlIFdHIHdpbGwgb3BlcmF0ZSB0aHJvdWdoIGEgc2VyaWVzIG9mIHZpcnR1YWwgaW50ZXJp bSBtZWV0aW5ncy4gVGhpcyANCj4gaXMgZHJpdmVuIGJ5IGEgbmVlZCB0byBpbnRlcmFjdCByZWd1 bGFybHkgd2l0aCBvdGhlciBpbmR1c3RyeSBncm91b3BzLCANCj4gYW5kIGR1ZSB0byB0aGUgdmFy aWV0eSBvZiB0b3BpY3Mgd2hpY2ggd2lsbCBub3QgYWx3YXlzIGJlIGFibGUgdG8gZ2V0IA0KPiBx dW9ydW0gYXMgYSBjb21taXR0ZWUgb2YgdGhlIHdob2xlLg0KPiANCj4ge3VudXN1YWwsIG1heWJl IG5vdCBjaGFydGVyIGFwcHJvcHJpYXRlLCBidXQgcmF0aGVyIHNhYWctbGlrZX0gRHVyaW5nIA0K PiBpbi1wZXJzb24gbWVldGluZ3MsIHRoZSBXRyB3aWxsIGRlYWwgd2l0aCB0eXBpY2FsIHN0YXR1 cyBhbmQgZG9jdW1lbnQgDQo+IHByb2dyZXNzIGlzc3VlcyBkdXJpbmcgb25lIGhvdXIgKG9yIGxl c3MpIG9mIHRoZSB0aW1lLCBhbmQgZHVyaW5nIA0KPiBhbm90aGVyIGhvdXIsIHdpbGwgYmUgb3Bl biB0byBzbGlkZXdhcmUgcHJlc2VudGF0aW9ucyBhbmQgdHV0b3JpYWxzIG9uIA0KPiBjdXJyZW50 IElFVEYgb3Igb3RoZXItU0RPIElvVCBlZmZvcnRzLiAgVGhlIGdvYWwgb2YgdGhlc2UgDQo+IHBy ZXNlbnRhdGlvbnMgaXMgdG8gcXVpY2tseSBjb21tdW5pY2F0ZSBjdXJyZW50IElvVCAqc3lzdGVt cyogc3RhdGUgdG8gdGhlIHJlc3Qgb2YgdGhlIElFVEYuDQo+IEl0IGlzIGFja25vd2xlZGdlZCB0 aGF0IHBhcnQgb2YgdGhlIHZhbHVlIGlzIGluIFlvdVR1YmUgY29udGVudCwgYW5kIA0KPiBzb21l IGNvbnRlbnQgc2hvdWxkIGJlIGRvbmUgYXQgSUFCIHRlY2ggcGxlbmFyaWVzIHJhdGhlciB0aGFu IGF0IHRoZSBXRy4NCj4gDQo+IFRoZSBpbml0aWFsIHNldCBvZiB3b3JrIGl0ZW1zIGlzIGluY2x1 ZGVkIGJlbG93IGFzIG1pbGVzdG9uZXMsIHdoaWNoIA0KPiBvbmx5IHJlcXVpcmUgQUQgYXBwcm92 YWwuDQo+IA0KPiBNaWxlc3RvbmVzDQo+IA0KPiAqIGFkb3B0IHRoZSBjb25zdHJhaW5lZC12b3Vj aGVyL2NvbnN0cmFpbmVkLUJSU0tJIHdvcmsgZnJvbSBBTklNQS4NCj4gKiBhZG9wdCB0aGUgZHRz ZWN1cml0eS16ZXJvLXRvdWNoIHdvcmsgZnJvbSA2dGlzY2gsIHdoaWNoIGNhbiBub3QgDQo+IGZp bmlzaCBiZWZvcmUgYSBMQUtFIGZpbmlzaGVzLg0KPiAqIGNyZWF0ZSBhIGxpc3Qgb2YgYSBzZXJp ZXMgb2YgTVVEIGV4dGVuc2lvbnMsIGFuZCByZXZpc2UgdGhpcyANCj4gbWlsZXN0b25lDQo+ICog YWRvcHQgYSBjbG91ZC1sZXNzIChNQVNBLWxlc3MsIEFBQS1sZXNzKSBvbmJvYXJkaW5nIG1lY2hh bmlzbSANCj4gKHBvc3NpYmx5IGEgdmVyc2lvbiBvZiBFQVAtTk9PQiksIHRoYXQgY2FuIGJlIHVz ZWQgYXQgdGhlIHJldGFpbCBsZXZlbC4NCj4gKiBuZWdvdGlhdGUgd2l0aCBFTVUgV0cgb24gaG93 IHRvIHByb2NlZWQgd2l0aCBURUFQLUJSU0tJLCBhbmQgcmV2aXNlIA0KPiB0aGlzIG1pbGVzdG9u ZS4NCj4gKiBhZG9wdCBhIGNsb3VkLWRyaXZlbiBvbmJvYXJkaW5nIG1lY2hhbmlzbSB0aGF0IGNh biBiZSB1c2VkIGluIA0KPiBjb21wbGV0ZWx5DQo+ICAgb2ZmbGluZSBzaXR1YXRpb25zIHdpdGhv dXQgcmVxdWlyaW5nIHJlbmV3YWxzIChwZXJoYXBzIHJldmlzaW5nIFJGQzgzNjYpLg0KPiANCj4g DQo+IC0tDQo+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4g byBPICggSVB2NiBJw7hUDQo+IGNvbnN1bHRpbmcgKQ0KPiAgICAgICAgICAgIFNhbmRlbG1hbiBT b2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQo+IA0KPiANCj4gDQoNCg== From nobody Fri Sep 18 14:58:11 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AEC3A096C; Fri, 18 Sep 2020 14:57:54 -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 z8tMSHOlJnvb; Fri, 18 Sep 2020 14:57:52 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDA93A0966; Fri, 18 Sep 2020 14:57:51 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 91AD91F4A9; Fri, 18 Sep 2020 21:57:50 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 816A51A022D; Fri, 18 Sep 2020 17:57:48 -0400 (EDT) From: Michael Richardson To: mud@ietf.org, iot-onboarding@ietf.org In-Reply-To: <13048.1599529310@localhost> References: <13048.1599529310@localhost> 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: [Mud] administrative control of devices --- thinking again about an IoT security WG X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 21:57:55 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > This includes: > * administrative control of devices Some have asked how big this effort would be. I think that it might rather small, and it does not have to a single soluti= on either. 90% of the challenge in building administrative interfaces is the authorization side. This is something that can be handled during onboardin= g. A RESTCONF interface might be enough. 1) https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ provides a way to update a WPA-PSK key for network access. 2) https://datatracker.ietf.org/doc/rfc8341/ and/or https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ provides a way to update who can manage the device.=20=20 3) I looked for a way to statically configure DNS server IPs into a devic= e, should one not be willing to use the Do53 ones from DHCP. There isn't such a thing, but I'll bet ADD WG would comment on such a document. I was actually looking for some network configuration ("MIB") YANG mod= ule, which I'm sure exists, but I'm not YANG expert. =20=20=20=20=20 4) https://datatracker.ietf.org/doc/draft-kwatsen-netconf-sztp-csr/ can be used to renew management interface certificates. Or the onboarding system might have an LDevID renewal process. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl9lLVwACgkQlUzhVv38 QpD2+Af/cv5ZZTbJSQVoogphmVmkYhgcebHyiR6a2f2ZmwtrUCD1smK8tz4x3mzm xqOFUUzKGaPk+w0JexBP/CNx6wRf1AEpS3sfXHX1pfU5OrbcVzyhqsm9a6jz9wd+ VuZnEMsy+MeUdZWnqVBQBgvWmWEHYStAAeZIJJ2d9y+FEl451+Q5t4M7WQezqL2g GfdPVZ6yqVDP/a0q/TjQD+z1JenllFmtc6AHSYZN8Gm6WDXAZoScRI/tPZ7MMrmh wUu3kU6Vw/iOPfr2djChB8Ib+V3g9tgqlkEBy80mKxHvbsighDtQdlwK8ePcZ5aT MKL0JQ6lJ2wTAO+Oiqs7Q0UgdGNREw== =9WlV -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 22 18:38:12 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62A3A09FB for ; Tue, 22 Sep 2020 18: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 Qmt2AhL5UwRL for ; Tue, 22 Sep 2020 18:38:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E253A09F7 for ; Tue, 22 Sep 2020 18:38:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A4B4389AB for ; Tue, 22 Sep 2020 21:16:42 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iHdv3wqBYQFj for ; Tue, 22 Sep 2020 21:16:38 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EE7338998 for ; Tue, 22 Sep 2020 21:16:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7A77C4F5 for ; Tue, 22 Sep 2020 21:38:00 -0400 (EDT) From: Michael Richardson to: mud@ietf.org In-Reply-To: <29621.1600819553@localhost> References: <160081804470.17462.16494692758703851063@ietfa.amsl.com> <29621.1600819553@localhost> 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: [Mud] [OPSAWG] changes to draft-richardson-opsawg-mud-acceptable-urls-02.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 01:38:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have updated draft-richardson-opsawg-mud-acceptable-urls. Here is a copy of my post to opsawg@ietf.org, which is presently where MUD = work is supposed to happen. (unless something happens soon to change that) Your comments CC to that list would be appreciated. I would welcome co-authors, particularly those with experience operationg D= NS servers for Content Distrbution Networks. There are a few places where I w= as unable to find a good reference. One relates to IP address literals in protocols, which I thought BEHAVE had a document on, but I didn't find the right place last time. Archived-At: Subject: [OPSAWG] changes to draft-richardson-opsawg-mud-acceptable-urls-0= 2.txt draft-richardson-opsawg-mud-acceptable-urls-00.txt was first discussed at IETF107, our "first" virtual IETF. The slides are at: https://www.ietf.org/proceedings/interim-2020-opsawg-01/slides/slides-inter= im-2020-opsawg-01-sessa-authorized-update-to-mud-urls-mud-acceptable-urls-00 I hope that the WG will consider adopting this document. I had suggested a few different ways to do things. Eliot suggested that I stick to common prefix of MUD URL, and asked to be an author, and I did that in -01. I have just done an editorial pass through the document. The diffs make for interesting read, but there are no significant technical changes. This document updates RFC8520 is a subtle semantic way: MUD controllers are being built now which should probably take this into account. The changes to semantics of the URL need to be taken into account by those hosting MUD files, but it's an easy and sensible way to organize things. The abstract could use some wordsmithing, and I would welcome edits. Dang, I forgot to include the github URL: https://github.com/mcr/iot-mud-ac= ceptable-urls Name: draft-richardson-opsawg-mud-acceptable-urls Revision: 02 Title: Authorized update to MUD URLs Document date: 2020-09-22 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/id/draft-richardson-opsawg-mud-accepta= ble-urls-02.txt Status: https://datatracker.ietf.org/doc/draft-richardson-opsawg-mu= d-acceptable-urls/ Htmlized: https://datatracker.ietf.org/doc/html/draft-richardson-opsa= wg-mud-acceptable-urls Htmlized: https://tools.ietf.org/html/draft-richardson-opsawg-mud-acc= eptable-urls-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-richardson-opsawg= -mud-acceptable-urls-02 Abstract: This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement URLs for a device. =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+93Q3WUFAl9qpvgACgkQgItw+93Q 3WU2Owf+P1nyHGvY3HlvXTz0XhfE8V7UY1qmvJF8xO+wpbJfGGRuwpkqkprxTu7/ BVV6R/WHCEhE8kcEPRkjMBfCYT00aVpXHDQutKuh+cT1oZQ0JY9TrMoxhlnjUt1P ptwdn8sfETW+DVTDUUZvsTLui2/GblvOyKsaow38sAt8ij+waWMQA7c62QEJLOOn SGW1xvAvF23eK0b0hnia3J5CIMFk3WLKH/71ykGM8vAIvNwdUoiS+5GOfj8rAk5D cXHl7B00k6wCQGgBI0ab4F63+Ilinkjk1h6yHhUlPOuvM0KWS3wLbNjJzXJLY7NP NyPRNWOmY6m8Uq+6eJMoqPeGne7Vng== =1bte -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 23 02:02:09 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6B3A0E95; Wed, 23 Sep 2020 02:02:07 -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 37x-zjMwzSjq; Wed, 23 Sep 2020 02:02:06 -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 D283B3A0E93; Wed, 23 Sep 2020 02:02:05 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B6FA76D8116B9DD7F8F0; Wed, 23 Sep 2020 10:02:03 +0100 (IST) Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) 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; Wed, 23 Sep 2020 10:01:56 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 23 Sep 2020 17:01:54 +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; Wed, 23 Sep 2020 17:01:54 +0800 From: "Panwei (William)" To: Michael Richardson CC: opsawg , "mud@ietf.org" Thread-Topic: I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt Thread-Index: AQHWkUkqmycj0obc10qWfbjonlTmQal14YfQ Date: Wed, 23 Sep 2020 09:01:54 +0000 Message-ID: References: <160082461405.2339.249127609152770744@ietfa.amsl.com> In-Reply-To: <160082461405.2339.249127609152770744@ietfa.amsl.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 09:02:08 -0000 SGkgTWljaGFlbCwNCg0KVGhpcyBpcyBhbiB2ZXJ5IHVzZWZ1bCBhbmQgZXNzZW50aWFsIGRyYWZ0 LCBJIHRoaW5rLiBUaGUgRE5TIHJlc29sdmluZyBpc3N1ZSBtYXkgYmUgYW4gaW1wb3J0YW50IG9i c3RhY2xlIGZvciBkZXBsb3lpbmcgTVVEIHNvbHV0aW9uIHN1Y2Nlc3NmdWxseS4NCg0KICAgVGhl IHNpbXBsZXN0IHN1Y2Nlc3NmdWwgc3RyYXRlZ3kgZm9yIHRyYW5zbGF0aW5nIG5hbWVzIGlzIGZv ciBhIE1VRA0KICAgY29udHJvbGxlciB0byB0YWtlIGlzIHRvIGRvIGEgRE5TIGxvb2t1cCBvbiB0 aGUgbmFtZSAoYSBmb3J3YXJkDQogICBsb29rdXApLCBhbmQgdGhlbiB1c2UgdGhlIHJlc3VsdGlu ZyBJUCBhZGRyZXNzZXMgdG8gcG9wdWxhdGUgdGhlDQogICBwaHlzaWNhbCBBQ0xzLg0KVGhpcyBz dHJhdGVneSBpcyBzaW1wbGUsIGJ1dCBJIGRvdWJ0IGl0IGNhbid0IGJlIGNhbGxlZCAnc3VjY2Vz c2Z1bCcgYXMgaXQgd29uJ3Qgd29yayBhbGwgdGhlIHRpbWUuIFlvdSBhbHJlYWR5IGxpc3RlZCBz b21lIGZhaWx1cmUgc2NlbmFyaW9zLg0KDQpCZXlvbmQgdGhlIGNvbnNpZGVyYXRpb25zIGluIHRo ZSBkcmFmdCwgYW5vdGhlciBtZXRob2QgSSBpbWFnaW5lIGlzIHRvIGRlcGxveSBhIEROUyBwcm94 eSAoYnV0IEkgZG9uJ3Qga25vdyB3aGV0aGVyIGl0J3MgcHJhY3RpY2FsKS4NCkluIHRoZSByZXNp ZGVudGlhbCBzY2VuYXJpbywgdGhlIENQRSBkZXZpY2UgaXMgdXN1YWxseSB0aGUgTVVEIGNvbnRy b2xsZXIgYW5kIHRoZSBwb2xpY3kgZW5mb3JjZW1lbnQgcG9pbnQsIGFuZCBpdCBjYW4gYWxzbyBh Y3QgYXMgYSBETlMgcHJveHkuIFdoZW4gdGhlIElvVCBkZXZpY2Ugc2VuZHMgYSBETlMgcXVlcnkg aXQgd2lsbCBzZW5kIHRvIHRoZSBDUEUuIEFuZCBDUEUgY2FuIGZpcnN0IGZpbHRlciB0aGUgdW5l eHBlY3RlZCBETlMgcXVlcnkgYnkgY29tcGFyaW5nIHRoZSBETlMgbmFtZXMgd2l0aCB0aGUgb25l cyBkZWZpbmVkIGluIHRoZSBNVUQgZmlsZSwgdGhlbiBDUEUgd2lsbCBxdWVyeSB0aGUgYWN0dWFs IEROUyBzZXJ2ZXIuIFdoZW4gdGhlIENQRSBnZXRzIHRoZSBhbnN3ZXJzIGZyb20gdGhlIGFjdHVh bCBETlMgc2VydmVyLCBpdCBjYW4gcmVzcG9uZCB0byB0aGUgSW9UIGRldmljZXMgd2l0aCB0aGUg YW5zd2VycyBhbmQgZ2VuZXJhdGUgdGhlIGNvcnJlc3BvbmRpbmcgQUNMcyBhcyBpdCBrbm93cyB0 aGUgSVAgYWRkcmVzc2VzIG5vdy4NCkluIHRoZSBlbnRlcnByaXNlIHNjZW5hcmlvLCB0aGUgTVVE IGNvbnRyb2xsZXIsIHRoZSBwb2xpY3kgZW5mb3JjZW1lbnQgcG9pbnQsIGFuZCB0aGUgRE5TIHBy b3h5IG1heSBiZSB0aHJlZSBkaWZmZXJlbnQgZGV2aWNlcy4gVGhlIE1VRCBjb250cm9sbGVyIGdl dHMgdGhlIE1VRCBmaWxlIG9mIHRoZSBJb1QgZGV2aWNlIGFuZCBkaXNwYXRjaCB0aGUgZmlsZSB0 byB0aGUgRE5TIHByb3h5LiBXaGVuIHRoZSBJb1QgZGV2aWNlIHNlbmRzIHRoZSBETlMgcXVlcnkg dG8gdGhlIEROUyBwcm94eSwgdGhlIEROUyBwcm94eSBjYW4gZmlsdGVyIHRoZSBETlMgcXVlcnkg YXMgd2VsbCBhbmQgdGhlbiBnZXQgdGhlIGFuc3dlcnMgYnkgcXVlcnlpbmcgdGhlIHJlYWwgRE5T IHNlcnZlci4gQWZ0ZXIgdGhhdCwgdGhlIEROUyBwcm94eSB3aWxsIHRlbGwgdGhlIElQIGFkZHJl c3NlcyBvZiB0aGUgRE5TIG5hbWVzIHRvIHRoZSBNVUQgY29udHJvbGxlciwgYW5kIHRoZSBNVUQg Y29udHJvbGxlciBjYW4gZ2VuZXJhdGUgdGhlIEFDTHMgYW5kIGNvbmZpZ3VyZSB0aGUgcG9saWN5 IGVuZm9yY2VtZW50IHBvaW50Lg0KSSdtIG5vdCBhbiBETlMgZXhwZXJ0LCBhbmQgdGhpcyBpcyBh IGxpdHRsZSB0aG91Z2h0LCBwbGVhc2UgZG9uJ3QgbWluZCBpZiBpdCdzIHVzZWxlc3MuDQoNClJl Z2FyZHMgJiBUaGFua3MhDQpXZWkgUGFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogSS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZg0KPiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gU2VudDogV2Vk bmVzZGF5LCBTZXB0ZW1iZXIgMjMsIDIwMjAgOTozMCBBTQ0KPiBUbzogaS1kLWFubm91bmNlQGll dGYub3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rpb246DQo+IGRyYWZ0LXJpY2hhcmRzb24tb3BzYXdn LW11ZC1pb3QtZG5zLWNvbnNpZGVyYXRpb25zLTAzLnR4dA0KPiANCj4gDQo+IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0K PiBkaXJlY3Rvcmllcy4NCj4gDQo+IA0KPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IE9wZXJh dGlvbmFsIENvbnNpZGVyYXRpb25zIGZvciB1c2Ugb2YgRE5TIGluIElvVA0KPiBkZXZpY2VzDQo+ ICAgICAgICAgQXV0aG9yICAgICAgICAgIDogTWljaGFlbCBSaWNoYXJkc29uDQo+IAlGaWxlbmFt ZSAgICAgICAgOg0KPiBkcmFmdC1yaWNoYXJkc29uLW9wc2F3Zy1tdWQtaW90LWRucy1jb25zaWRl cmF0aW9ucy0wMy50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDEzDQo+IAlEYXRlICAgICAgICAg ICAgOiAyMDIwLTA5LTIyDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBkZXRh aWxzIGNvbmNlcm5zIGFib3V0IGhvdyBJbnRlcm5ldCBvZiBUaGluZ3MgZGV2aWNlcw0KPiAgICB1 c2UgSVAgYWRkcmVzc2VzIGFuZCBETlMgbmFtZXMuICBUaGUgaXNzdWUgYmVjb21lcyBhY3V0ZSBh cyBuZXR3b3JrDQo+ICAgIG9wZXJhdG9ycyBiZWdpbiBkZXBsb3lpbmcgUkZDODUyMCBNYW51ZmFj dHVyZXIgVXNhZ2UgRGVzY3JpcHRpb24NCj4gICAgKE1VRCkgZGVmaW5pdGlvbnMgdG8gY29udHJv bCBkZXZpY2UgYWNjZXNzLg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBleHBsYWlucyB0aGUgcHJv YmxlbSB0aHJvdWdoIGEgc2VyaWVzIG9mIGV4YW1wbGVzIG9mDQo+ICAgIHdoYXQgY2FuIGdvIHdy b25nLCBhbmQgdGhlbiBwcm92aWRlcyBzb21lIGFkdmljZSBvbiBob3cgYSBkZXZpY2UNCj4gICAg bWFudWZhY3R1cmVyIGNhbiBiZXN0IG1ha2UgZGVhbCB3aXRoIHRoZXNlIGlzc3Vlcy4gIFRoZQ0K PiAgICByZWNvbW1lbmRhdGlvbnMgaGF2ZSBhbiBpbXBhY3QgdXBvbiBkZXZpY2UgYW5kIG5ldHdv cmsgcHJvdG9jb2wNCj4gICAgZGVzaWduLg0KPiANCj4gICAge1JGQy1FRElUT1IsIHBsZWFzZSBy ZW1vdmUuICBNYXJrZG93biBhbmQgaXNzdWUgdHJhY2tlciBmb3IgdGhpcw0KPiAgICBkb2N1bWVu dCBpcyBhdCBodHRwczovL2dpdGh1Yi5jb20vbWNyL2lvdC1tdWQtZG5zLWNvbnNpZGVyYXRpb25z LmdpdA0KPiAgICB9DQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXJpY2hhcmRzb24tb3BzYXdnLW11ZC1pb3QtZG5zLWNvbg0KPiBzaWRlcmF0aW9ucy8NCj4g DQo+IFRoZXJlIGlzIGFsc28gYSBIVE1MIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcmljaGFyZHNvbi1vcHNhd2ctbXVkLWlvdC1kbnMtY29u c2lkZXJhdGkNCj4gb25zLTAzLmh0bWwNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LXJpY2hhcmRzb24tb3BzYXdnLW11ZC1pb3QtZG5zLWNvDQo+IG5zaWRlcmF0aW9u cy0wMw0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+ IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJLUQtQW5ub3VuY2Ug bWFpbGluZyBsaXN0DQo+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiBJbnRlcm5ldC1EcmFmdCBkaXJl Y3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0KPiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K From nobody Wed Sep 23 11:27:54 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562CC3A1365; Wed, 23 Sep 2020 11:27:48 -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 9no4t7CWrcpz; Wed, 23 Sep 2020 11:27:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D96E3A1363; Wed, 23 Sep 2020 11:27:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C52E389BD; Wed, 23 Sep 2020 14:06:20 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JyCgsccQm_x5; Wed, 23 Sep 2020 14:06:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C679838993; Wed, 23 Sep 2020 14:06:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B3E32373; Wed, 23 Sep 2020 14:27:41 -0400 (EDT) From: Michael Richardson To: "Panwei \(William\)" , opsawg , "mud\@ietf.org" In-Reply-To: References: <160082461405.2339.249127609152770744@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: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 18:27:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Panwei (William) wrote: > This is an very useful and essential draft, I think. The DNS resolving > issue may be an important obstacle for deploying MUD solution > successfully. Thank you. mcr> The simplest successful strategy for translating names is for a MUD mcr> controller to take is to do a DNS lookup on the name (a forward mcr> lookup), and then use the resulting IP addresses to populate the mcr> physical ACLs. > This strategy is simple, but I doubt it can't be called 'successful' = as > it won't work all the time. You already listed some failure scenarios. Okay, so maybe my words are not perfect. Please suggest some better ones h= ere. The naive method of using the reverse map never works :-) (Some people read RFC1034/35 and think that DNS inverse queries are still a= thing) This method is the simplest that can be made to work. The rest of the document is really about making this method work. > Beyond the considerations in the draft, another method I imagine is to > deploy a DNS proxy (but I don't know whether it's practical). I am not sure what you call a DNS proxy. A recursive DNS server accessed by Do53 effectively proxies and caches all = requests. > In the residential scenario, the CPE device is usually the MUD > controller and the policy enforcement point, and it can also act as a > DNS proxy. > When the IoT device sends a DNS query it will send to the > CPE. And CPE can first filter the unexpected DNS query by comparing t= he > DNS names with the ones defined in the MUD file, then CPE will query > the actual DNS server. Yes, the CPE could look at the DNS queries the device is using, and then cache them. Or, when it loads the MUD file, it could do a DNS lookup on a= ll the names, and cache them. Then, when the device asks, it is already cache= d, and one can be sure that a known IP/name combination is returned. If it does this DNS lookup on a regular basis (updating the MUD ACLs implemented in the forwarding plane), then the cache stays warm, and the rules are accurate. This is how our implementation worked. > When the CPE gets the answers from the actual > DNS server, it can respond to the IoT devices with the answers and > generate the corresponding ACLs as it knows the IP addresses now. If you can generate the ACL on demand fast enough, it can work. Many IoT devices, if DNS seems slow, will switch to 8.8.8.8. Google Chromecast for instance, always sends to both local and 8.8.8.8 from what I've read, and uses which ever is faster. > In the enterprise scenario, the MUD controller, the policy enforcement > point, and the DNS proxy may be three different devices. The MUD > controller gets the MUD file of the IoT device and dispatch the file = to > the DNS proxy. When the IoT device sends the DNS query to the DNS > proxy, the DNS proxy can filter the DNS query as well and then get the > answers by querying the real DNS server. After that, the DNS proxy wi= ll > tell the IP addresses of the DNS names to the MUD controller, and the > MUD controller can generate the ACLs and configure the policy > enforcement point. Sure, that's essentially correct. The DNS proxy is just the local recursive resolver. What counts is that the MUD controller and the IoT device use the same recursive resolver, and see the same cache. =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+93Q3WUFAl9rk50ACgkQgItw+93Q 3WWcfQf/TpcNlnAFQd/aNDNmfUilNB3ORBDKV2ZWgPrvJrHQOYLnU+YLyr2V1PGh aQv04E6KkAUN/SaCFy0YX9Uf+EJr9GfoZ6Hs8vcw97ZUpjxNelIPOdK73VV8iEmB sv9RYLvVYQYvAy1dsApx1AF2tcuDhXhcQXgfl0H/RpGlFAi3nBnWUNr4NqeHhX7N il3pSeu6qOkscg4n0KmOwIs7Ruy0MfxGUrq8EG5s95UDIRcbpYceQkOsF0ZE54RP wBE4CChsMusTTCGWChENaiBALOrBONxrSt5Iq4pTEGVcc7yRfviIlkcCL8eWL9bX ox6yixyeJA7FWN4MWd6wCTzxJFTDXw== =TJb4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 23 19:40:22 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4563A171D; Wed, 23 Sep 2020 19:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 hM0fAacXixNA; Wed, 23 Sep 2020 19:40:14 -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 431273A0A90; Wed, 23 Sep 2020 19:40:14 -0700 (PDT) Received: from lhreml706-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0ABA85A297D9E94F9BE0; Thu, 24 Sep 2020 03:40:11 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 24 Sep 2020 03:40:10 +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; Thu, 24 Sep 2020 10:40:08 +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; Thu, 24 Sep 2020 10:40:08 +0800 From: "Panwei (William)" To: Michael Richardson CC: opsawg , "mud@ietf.org" Thread-Topic: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt Thread-Index: AQHWkUkqmycj0obc10qWfbjonlTmQal14YfQgAAkO4CAAQBuQA== Date: Thu, 24 Sep 2020 02:40:07 +0000 Message-ID: References: <160082461405.2339.249127609152770744@ietfa.amsl.com> <16821.1600885661@localhost> In-Reply-To: <16821.1600885661@localhost> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 02:40:16 -0000 SGkgTWljaGFlbCwNCg0KPiA+IEJleW9uZCB0aGUgY29uc2lkZXJhdGlvbnMgaW4gdGhlIGRyYWZ0 LCBhbm90aGVyIG1ldGhvZCBJIGltYWdpbmUgaXMNCj4gPiB0byBkZXBsb3kgYSBETlMgcHJveHkg KGJ1dCBJIGRvbid0IGtub3cgd2hldGhlciBpdCdzIHByYWN0aWNhbCkuDQo+IA0KPiBJIGFtIG5v dCBzdXJlIHdoYXQgeW91IGNhbGwgYSBETlMgcHJveHkuDQo+IEEgcmVjdXJzaXZlIEROUyBzZXJ2 ZXIgYWNjZXNzZWQgYnkgRG81MyBlZmZlY3RpdmVseSBwcm94aWVzIGFuZCBjYWNoZXMgYWxsDQo+ IHJlcXVlc3RzLg0KDQpUaGUgRE5TIHByb3h5IEkgY2FsbCBtb3JlIGxpa2VzIGEgbWlkZGxlLWJv eCwgSSB0aGluay4gSSBtZWFuIHdoZW4gdGhlIElvVCBkZXZpY2Ugb25ib2FyZGluZywgdGhlIENQ RS9BY2Nlc3MgUG9pbnQgY2FuIHByb3Zpc2lvbiB0aGUgSW9UIGRldmljZSB3aXRoIHRoZSBJUCBh ZGRyZXNzIG9mIHRoZSBETlMgcHJveHkgcmF0aGVyIHRoYW4gdGhlIHJlYWwgRE5TIHNlcnZlci4N CiANCj4gPiBJbiB0aGUgcmVzaWRlbnRpYWwgc2NlbmFyaW8sIHRoZSBDUEUgZGV2aWNlIGlzIHVz dWFsbHkgdGhlIE1VRA0KPiA+IGNvbnRyb2xsZXIgYW5kIHRoZSBwb2xpY3kgZW5mb3JjZW1lbnQg cG9pbnQsIGFuZCBpdCBjYW4gYWxzbyBhY3QgYXMgYQ0KPiA+IEROUyBwcm94eS4NCj4gDQo+ID4g V2hlbiB0aGUgSW9UIGRldmljZSBzZW5kcyBhIEROUyBxdWVyeSBpdCB3aWxsIHNlbmQgdG8gdGhl DQo+ID4gQ1BFLiBBbmQgQ1BFIGNhbiBmaXJzdCBmaWx0ZXIgdGhlIHVuZXhwZWN0ZWQgRE5TIHF1 ZXJ5IGJ5IGNvbXBhcmluZw0KPiA+IHRoZSBETlMgbmFtZXMgd2l0aCB0aGUgb25lcyBkZWZpbmVk IGluIHRoZSBNVUQgZmlsZSwgdGhlbiBDUEUgd2lsbA0KPiA+IHF1ZXJ5IHRoZSBhY3R1YWwgRE5T IHNlcnZlci4NCj4gDQo+IFllcywgdGhlIENQRSBjb3VsZCBsb29rIGF0IHRoZSBETlMgcXVlcmll cyB0aGUgZGV2aWNlIGlzIHVzaW5nLCBhbmQgdGhlbg0KPiBjYWNoZSB0aGVtLiAgIE9yLCB3aGVu IGl0IGxvYWRzIHRoZSBNVUQgZmlsZSwgaXQgY291bGQgZG8gYSBETlMgbG9va3VwIG9uDQo+IGFs bCB0aGUgbmFtZXMsIGFuZCBjYWNoZSB0aGVtLiAgVGhlbiwgd2hlbiB0aGUgZGV2aWNlIGFza3Ms IGl0IGlzIGFscmVhZHkNCj4gY2FjaGVkLCBhbmQgb25lIGNhbiBiZSBzdXJlIHRoYXQgYSBrbm93 biBJUC9uYW1lIGNvbWJpbmF0aW9uIGlzDQo+IHJldHVybmVkLg0KDQpJIHRoaW5rIHRoZSAnY2Fj aGUnIGhlcmUgbWVhbnMgYSBwcmUtcXVlcnkuIEJ1dCB0aGUgY2FjaGVkIElQL25hbWUgbWF5IGJl IGluY29ycmVjdCBpZiB0aGUgcmVhbCBETlMgc2VydmVyIGNoYW5nZXMgdGhlIGFuc3dlci4NCldo YXQgSSBzdWdnZXN0IGlzIG5vIHByZS1xdWVyaWVzLiBUaGUgSW9UIGRldmljZSBzZW5kcyBhIERO UyBxdWVyeSB0byB0aGUgRE5TIHByb3h5LCBhbmQgdGhlIEROUyBwcm94eSBxdWVyaWVzIHRoZSBy ZWFsIEROUyBzZXJ2ZXIuIFNvIHRoZSBETlMgcHJveHkgY2FuIDEpIGZpbHRlciB0aGUgaWxsZWdh bCBETlMgcXVlcmllcyB3aGljaCBhcmUgbm90IGRlZmluZWQgaW4gdGhlIE1VRCBmaWxlLCBhbmQg Mikga25vdyB0aGUgRE5TIGFuc3dlciBleGFjdGx5IHdpdGggdGhlIElvVCBkZXZpY2UuDQoNCj4g SWYgaXQgZG9lcyB0aGlzIEROUyBsb29rdXAgb24gYSByZWd1bGFyIGJhc2lzICh1cGRhdGluZyB0 aGUgTVVEIEFDTHMNCj4gaW1wbGVtZW50ZWQgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUpLCB0aGVu IHRoZSBjYWNoZSBzdGF5cyB3YXJtLCBhbmQgdGhlDQo+IHJ1bGVzIGFyZSBhY2N1cmF0ZS4NCj4g DQo+IFRoaXMgaXMgaG93IG91ciBpbXBsZW1lbnRhdGlvbiB3b3JrZWQuDQo+IA0KPiA+IFdoZW4g dGhlIENQRSBnZXRzIHRoZSBhbnN3ZXJzIGZyb20gdGhlIGFjdHVhbA0KPiA+IEROUyBzZXJ2ZXIs IGl0IGNhbiByZXNwb25kIHRvIHRoZSBJb1QgZGV2aWNlcyB3aXRoIHRoZSBhbnN3ZXJzIGFuZA0K PiA+IGdlbmVyYXRlIHRoZSBjb3JyZXNwb25kaW5nIEFDTHMgYXMgaXQga25vd3MgdGhlIElQIGFk ZHJlc3NlcyBub3cuDQo+IA0KPiBJZiB5b3UgY2FuIGdlbmVyYXRlIHRoZSBBQ0wgb24gZGVtYW5k IGZhc3QgZW5vdWdoLCBpdCBjYW4gd29yay4NCj4gTWFueSBJb1QgZGV2aWNlcywgaWYgRE5TIHNl ZW1zIHNsb3csIHdpbGwgc3dpdGNoIHRvIDguOC44LjguDQo+IEdvb2dsZSBDaHJvbWVjYXN0IGZv ciBpbnN0YW5jZSwgYWx3YXlzIHNlbmRzIHRvIGJvdGggbG9jYWwgYW5kIDguOC44LjggZnJvbQ0K PiB3aGF0IEkndmUgcmVhZCwgYW5kIHVzZXMgd2hpY2ggZXZlciBpcyBmYXN0ZXIuDQoNClRoZSBD UEUgY2FuIGJsb2NrIHRoZSBETlMgcXVlcnkgdG8gOC44LjguOCBhbmQgZm9yY2UgdGhlIElvVCBk ZXZpY2UgdG8gd2FpdC4NCg0KPiA+IEluIHRoZSBlbnRlcnByaXNlIHNjZW5hcmlvLCB0aGUgTVVE IGNvbnRyb2xsZXIsIHRoZSBwb2xpY3kgZW5mb3JjZW1lbnQNCj4gPiBwb2ludCwgYW5kIHRoZSBE TlMgcHJveHkgbWF5IGJlIHRocmVlIGRpZmZlcmVudCBkZXZpY2VzLiBUaGUgTVVEDQo+ID4gY29u dHJvbGxlciBnZXRzIHRoZSBNVUQgZmlsZSBvZiB0aGUgSW9UIGRldmljZSBhbmQgZGlzcGF0Y2gg dGhlIGZpbGUgdG8NCj4gPiB0aGUgRE5TIHByb3h5LiBXaGVuIHRoZSBJb1QgZGV2aWNlIHNlbmRz IHRoZSBETlMgcXVlcnkgdG8gdGhlIEROUw0KPiA+IHByb3h5LCB0aGUgRE5TIHByb3h5IGNhbiBm aWx0ZXIgdGhlIEROUyBxdWVyeSBhcyB3ZWxsIGFuZCB0aGVuIGdldA0KPiA+IHRoZSBhbnN3ZXJz IGJ5IHF1ZXJ5aW5nIHRoZSByZWFsIEROUyBzZXJ2ZXIuIEFmdGVyIHRoYXQsIHRoZSBETlMgcHJv eHkNCj4gPiB3aWxsIHRlbGwgdGhlIElQIGFkZHJlc3NlcyBvZiB0aGUgRE5TIG5hbWVzIHRvIHRo ZSBNVUQgY29udHJvbGxlciwgYW5kDQo+ID4gdGhlIE1VRCBjb250cm9sbGVyIGNhbiBnZW5lcmF0 ZSB0aGUgQUNMcyBhbmQgY29uZmlndXJlIHRoZSBwb2xpY3kNCj4gPiBlbmZvcmNlbWVudCBwb2lu dC4NCj4gDQo+IFN1cmUsIHRoYXQncyBlc3NlbnRpYWxseSBjb3JyZWN0Lg0KPiBUaGUgRE5TIHBy b3h5IGlzIGp1c3QgdGhlIGxvY2FsIHJlY3Vyc2l2ZSByZXNvbHZlci4NCj4gV2hhdCBjb3VudHMg aXMgdGhhdCB0aGUgTVVEIGNvbnRyb2xsZXIgYW5kIHRoZSBJb1QgZGV2aWNlIHVzZSB0aGUgc2Ft ZQ0KPiByZWN1cnNpdmUgcmVzb2x2ZXIsIGFuZCBzZWUgdGhlIHNhbWUgY2FjaGUuDQoNClllcy4N CkFsc28sIEkgYXNzdW1lIHRoZSBJb1QgZGV2aWNlIHdvbid0IGRvIEROUyBsb29rdXAgZnJlcXVl bnRseSwgc28gdXBkYXRpbmcgdGhlIGNhY2hlIGVhY2ggdGltZSB3aGVuIHRoZSBJb1QgZGV2aWNl IHNlbmRzIHRoZSBETlMgcXVlcnkgY2FuIGJlIGFjY2VwdGFibGUuDQoNClJlZ2FyZHMgJiBUaGFu a3MhDQpXZWkgUGFuDQo= From nobody Thu Sep 24 01:38:09 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FD33A0A21; Thu, 24 Sep 2020 01:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 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 PLKc45t17i8v; Thu, 24 Sep 2020 01:37:55 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70D53A0A24; Thu, 24 Sep 2020 01:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10148; q=dns/txt; s=iport; t=1600936675; x=1602146275; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=zFuXD8LKF1anQfnKXtZ07UdOciG0Sd80eIek6Ul6oRw=; b=A9y+QGt+ru0e8s9bsrcIxJyTulo1xbaxIzLtRg6YOvvH53puKReO/rpz nvBXN6Gdg5HlPM1v6Fu2hRrHGn/GvzE+Gh60gzJQCdZwD8c/l9XP2hy19 KT0zep5RIl4nEXO/G9YdyIIvjm5LoT4G7BVuT/Jfl/5TSRIoGnfRlTLgN I=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BYAADMWWxf/xbLJq1gGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgSOBB4FFASASLI0+iEGHY4wliBkEBwEBAQoDAQEvBAEBh?= =?us-ascii?q?EsCgislOBMCAwEBAQMCAwEBAQEFAQEBAgEGBG2FaIVyAQEBAQIBcgcFCwsYL?= =?us-ascii?q?lcGE4MmAYJcILUbdIE0hVOFBhCBOIFTi3SCAIE4HIJNPogHgi0EmlaBGZtEg?= =?us-ascii?q?nGDE4E0iweLBQMfoQqvI4NcAgQGBQIVgWsjKoEtMxoIGxVlAYI+PhIZDY5Wj?= =?us-ascii?q?hI/AzA3AgYKAQEDCZAeAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,296,1596499200"; d="asc'?scan'208,217";a="27445632" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2020 08:37:50 +0000 Received: from dhcp-10-61-109-24.cisco.com (dhcp-10-61-109-24.cisco.com [10.61.109.24]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 08O8bnwq011661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Sep 2020 08:37:50 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C657F58C-B383-42F4-A29E-E38C671793A4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 24 Sep 2020 10:37:49 +0200 In-Reply-To: <16821.1600885661@localhost> Cc: "Panwei (William)" , opsawg , "mud@ietf.org" To: Michael Richardson References: <160082461405.2339.249127609152770744@ietfa.amsl.com> <16821.1600885661@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.109.24, dhcp-10-61-109-24.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] [OPSAWG] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 08:38:04 -0000 --Apple-Mail=_C657F58C-B383-42F4-A29E-E38C671793A4 Content-Type: multipart/alternative; boundary="Apple-Mail=_5F7E74CA-325A-4A5A-B83D-1FEAD68A921F" --Apple-Mail=_5F7E74CA-325A-4A5A-B83D-1FEAD68A921F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 23 Sep 2020, at 20:27, Michael Richardson = wrote: >=20 > Yes, the CPE could look at the DNS queries the device is using, and = then > cache them. Or, when it loads the MUD file, it could do a DNS lookup = on all > the names, and cache them. Then, when the device asks, it is already = cached, > and one can be sure that a known IP/name combination is returned. > If it does this DNS lookup on a regular basis (updating the MUD ACLs > implemented in the forwarding plane), then the cache stays warm, and = the > rules are accurate. >=20 > This is how our implementation worked. Either this, or there should be a relationship between the resolver and = the AP/switch/firewall/CPE in which appropriate query responses are = shared. That might be the better long term approach. What is key- in = order for protection to work, the infrastructure needs to know (1) what = names are authorized and (b) their associated addresses. As important, = its understanding must be the same as that of the device that makes the = query. Eliot --Apple-Mail=_5F7E74CA-325A-4A5A-B83D-1FEAD68A921F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On 23 Sep 2020, at 20:27, Michael Richardson = <mcr+ietf@sandelman.ca> wrote:

Yes, the CPE could look at the = DNS queries the device is using, and then
cache them.   Or, when it loads the MUD file, it = could do a DNS lookup on all
the names, and cache them.  Then, when the device asks, = it is already cached,
and one can be sure that a known IP/name combination is = returned.
If it does = this DNS lookup on a regular basis (updating the MUD ACLs
implemented in the forwarding = plane), then the cache stays warm, and the
rules are accurate.

This is how our implementation = worked.

Either this, or there should be a relationship between the = resolver and the AP/switch/firewall/CPE in which appropriate query = responses are shared. That might be the better long term approach. =  What is key- in order for protection to work, the infrastructure = needs to know (1) what names are authorized and (b) their associated = addresses.  As important, its understanding must be the same as = that of the device that makes the query.

Eliot
= --Apple-Mail=_5F7E74CA-325A-4A5A-B83D-1FEAD68A921F-- --Apple-Mail=_C657F58C-B383-42F4-A29E-E38C671793A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl9sWt0ACgkQh7ZrRtnS ejMVfggAvcdeu5ejSthJ0gDBm3+PN+/6vtaQlqeb6u0SGuTar2CE9qXgfSF+2xiu FeFZF7c1/Ej3bGD9fj+P9ylQZolRLedluRJyRqbBhPcNTqzxW8DVmmjtqz9G0aFm u8XIr3C7o35ch6AayEUMX1BAw9niJIqQ42YDs8PBZGAMiTtM4ORseHrTeQpYjErO NsVjhFRPKMKddCbpVskcNW8EaprobZAjUVF0DTaGgcAT1pWLZ2xE2SG9ob2SLGlD u5Ifj8zSwHZaRYrqTnVrbTe4mcfNhfIiLcUGKyJgpO6je/tZS/MqP8lUqt50Fxsm V1pceB5TuDG6vOKy6BnGlNjac0V0cg== =dhu1 -----END PGP SIGNATURE----- --Apple-Mail=_C657F58C-B383-42F4-A29E-E38C671793A4-- From nobody Thu Sep 24 03:51:59 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE043A0906; Thu, 24 Sep 2020 03:51:57 -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 QB7wg2gyvqQn; Thu, 24 Sep 2020 03:51:56 -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 389723A08F8; Thu, 24 Sep 2020 03:51:56 -0700 (PDT) Received: from lhreml748-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 962D17794BB4BBF40F92; Thu, 24 Sep 2020 11:51:51 +0100 (IST) Received: from lhreml748-chm.china.huawei.com (10.201.108.198) by lhreml748-chm.china.huawei.com (10.201.108.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 24 Sep 2020 11:51:51 +0100 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml748-chm.china.huawei.com (10.201.108.198) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 24 Sep 2020 11:51:51 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.160]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Thu, 24 Sep 2020 18:51:46 +0800 From: Qin Wu To: Michael Richardson , "mud@ietf.org" , "iot-onboarding@ietf.org" Thread-Topic: [Iot-onboarding] administrative control of devices --- thinking again about an IoT security WG Thread-Index: AdaSYDAbdXizPTyAQwqQjwr3bR5d+Q== Date: Thu, 24 Sep 2020 10:51:46 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Mud] [Iot-onboarding] administrative control of devices --- thinking again about an IoT security WG X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 10:51:58 -0000 SGF2ZSB3ZSBjb25zaWRlcmVkIHRvIG1hbmFnZSBtdWx0aXBsZSBkZXZpY2VzIG9uIGJvYXJkaW5n IGF0IG9uZSB0aW1lPw0KVGhlc2UgZGV2aWNlcyBtaWdodCBiZSBwbGFjZWQgYmVoaW5kIHRoZSBz YW1lIGdhdGV3YXkgZGV2aWNlLiBJbiBzb21lIGNhc2VzLCB0aGVyZSBpcyBubyBETlMgaW5mcmFz dHJ1Y3R1cmUgb3IgREhDUC4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IElv dC1vbmJvYXJkaW5nIFttYWlsdG86aW90LW9uYm9hcmRpbmctYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBNaWNoYWVsIFJpY2hhcmRzb24NCreiy83KsbzkOiAyMDIwxOo51MIxOcjVIDU6NTgNCsrVvP7I yzogbXVkQGlldGYub3JnOyBpb3Qtb25ib2FyZGluZ0BpZXRmLm9yZw0K1vfM4jogW0lvdC1vbmJv YXJkaW5nXSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9mIGRldmljZXMgLS0tIHRoaW5raW5nIGFn YWluIGFib3V0IGFuIElvVCBzZWN1cml0eSBXRw0KDQoNCk1pY2hhZWwgUmljaGFyZHNvbiA8bWNy K2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCiAgICA+IFRoaXMgaW5jbHVkZXM6DQogICAgPiAq IGFkbWluaXN0cmF0aXZlIGNvbnRyb2wgb2YgZGV2aWNlcw0KDQpTb21lIGhhdmUgYXNrZWQgaG93 IGJpZyB0aGlzIGVmZm9ydCB3b3VsZCBiZS4NCkkgdGhpbmsgdGhhdCBpdCBtaWdodCByYXRoZXIg c21hbGwsIGFuZCBpdCBkb2VzIG5vdCBoYXZlIHRvIGEgc2luZ2xlIHNvbHV0aW9uIGVpdGhlci4g IDkwJSBvZiB0aGUgY2hhbGxlbmdlIGluIGJ1aWxkaW5nIGFkbWluaXN0cmF0aXZlIGludGVyZmFj ZXMgaXMgdGhlIGF1dGhvcml6YXRpb24gc2lkZS4gIFRoaXMgaXMgc29tZXRoaW5nIHRoYXQgY2Fu IGJlIGhhbmRsZWQgZHVyaW5nIG9uYm9hcmRpbmcuDQoNCkEgUkVTVENPTkYgaW50ZXJmYWNlIG1p Z2h0IGJlIGVub3VnaC4NCiAgMSkgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRjb25mLWtleXN0b3JlLyBwcm92aWRlcw0KICAgICBhIHdheSB0byB1cGRhdGUg YSBXUEEtUFNLIGtleSBmb3IgbmV0d29yayBhY2Nlc3MuDQoNCiAgMikgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvcmZjODM0MS8gYW5kL29yDQogICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi10cnVzdC1hbmNob3JzLw0KICAgICBw cm92aWRlcyBhIHdheSB0byB1cGRhdGUgd2hvIGNhbiBtYW5hZ2UgdGhlIGRldmljZS4gIA0KDQog IDMpIEkgbG9va2VkIGZvciBhIHdheSB0byBzdGF0aWNhbGx5IGNvbmZpZ3VyZSBETlMgc2VydmVy IElQcyBpbnRvIGEgZGV2aWNlLA0KICAgICBzaG91bGQgb25lIG5vdCBiZSB3aWxsaW5nIHRvIHVz ZSB0aGUgRG81MyBvbmVzIGZyb20gREhDUC4gIFRoZXJlIGlzbid0DQogICAgIHN1Y2ggYSB0aGlu ZywgYnV0IEknbGwgYmV0IEFERCBXRyB3b3VsZCBjb21tZW50IG9uIHN1Y2ggYSBkb2N1bWVudC4N CiAgICAgSSB3YXMgYWN0dWFsbHkgbG9va2luZyBmb3Igc29tZSBuZXR3b3JrIGNvbmZpZ3VyYXRp b24gKCJNSUIiKSBZQU5HIG1vZHVsZSwgd2hpY2gNCiAgICAgSSdtIHN1cmUgZXhpc3RzLCBidXQg SSdtIG5vdCBZQU5HIGV4cGVydC4NCiAgICAgDQogIDQpIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWt3YXRzZW4tbmV0Y29uZi1zenRwLWNzci8NCiAgICAgY2FuIGJlIHVz ZWQgdG8gcmVuZXcgbWFuYWdlbWVudCBpbnRlcmZhY2UgY2VydGlmaWNhdGVzLiAgT3IgdGhlDQog ICAgIG9uYm9hcmRpbmcgc3lzdGVtIG1pZ2h0IGhhdmUgYW4gTERldklEIHJlbmV3YWwgcHJvY2Vz cy4NCg0KLS0gDQpdICAgICAgICAgICAgICAgTmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgICAgICAg ICAgICAgICAgIHwgaXB2NiBtZXNoIG5ldHdvcmtzIFsgDQpdICAgTWljaGFlbCBSaWNoYXJkc29u LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgICAgICAgIHwgbmV0d29yayBhcmNoaXRlY3QgIFsg DQpdICAgICBtY3JAc2FuZGVsbWFuLmNhICBodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8gICAgICAg IHwgICBydWJ5IG9uIHJhaWxzICAgIFsgDQoJDQo= From nobody Thu Sep 24 07:43:41 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3CB3A0CB4; Thu, 24 Sep 2020 07:43:39 -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 ADa6RziQFxgg; Thu, 24 Sep 2020 07:43:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BAE3A0D47; Thu, 24 Sep 2020 07:43:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 30C8F389BC; Thu, 24 Sep 2020 10:22:01 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rPCrjnzXm9sr; Thu, 24 Sep 2020 10:21:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C5BAC389B4; Thu, 24 Sep 2020 10:21:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 85145824; Thu, 24 Sep 2020 10:43:22 -0400 (EDT) From: Michael Richardson To: "Panwei \(William\)" , opsawg , "mud\@ietf.org" In-Reply-To: References: <160082461405.2339.249127609152770744@ietfa.amsl.com> <16821.1600885661@localhost> 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: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 14:43:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Panwei (William) wrote: >> Yes, the CPE could look at the DNS queries the device is using, and = then >> cache them. Or, when it loads the MUD file, it could do a DNS look= up on >> all the names, and cache them. Then, when the device asks, it is al= ready >> cached, and one can be sure that a known IP/name combination is >> returned. > I think the 'cache' here means a pre-query. But the cached IP/name may > be incorrect if the real DNS server changes the answer. That's why an extra layer of proxy is not helpful: it's already present. No additional middle boxes are needed. A recursive DNS server caches answers and, in a sense proxies, the question. It pays attention to the provided TTL, and expires the data when it happens. The MUD controller needs to know the TTL of all things it looks up, so that it can look them up again before the TTL expires. The operator of the service can't update their servers faster than the TTL anyway (because clients can cache the result), so there won't be any inconsistency. A DNS TTL of 0 is permitted however, and either this document needs to reco= mmend against doing that, or provide some guidance. I'm not sure what the right answer yet. > What I suggest is no pre-queries. The IoT device sends a DNS query to > the DNS proxy, and the DNS proxy queries the real DNS server. So the > DNS proxy can 1) filter the illegal DNS queries which are not defined > in the MUD file, and 2) know the DNS answer exactly with the IoT > device. I see. This depends upon the IoT query always travelling via the same path to the same recursive DNS server. That's why you've put this proxy in place. I think that this just introduces an additional single point of failure, wh= en DNS has already provided redundancy. That is, it makes DNS less reliable. Doing the queries when installing the ACLs leverages the resilience rather than reduces it. Perhaps, however, the MUD controller should perform the query to all recursive DNS servers and should merge the results if they are not identical. >> If you can generate the ACL on demand fast enough, it can work. >> Many IoT devices, if DNS seems slow, will switch to 8.8.8.8. >> Google Chromecast for instance, always sends to both local and 8.8.8= .8 from >> what I've read, and uses which ever is faster. > The CPE can block the DNS query to 8.8.8.8 and force the IoT device t= o wait. It could do that. >> > In the enterprise scenario, the MUD controller, the policy enforce= ment >> > point, and the DNS proxy may be three different devices. The MUD >> > controller gets the MUD file of the IoT device and dispatch the fi= le to >> > the DNS proxy. When the IoT device sends the DNS query to the DNS >> > proxy, the DNS proxy can filter the DNS query as well and then get >> > the answers by querying the real DNS server. After that, the DNS p= roxy >> > will tell the IP addresses of the DNS names to the MUD controller,= and >> > the MUD controller can generate the ACLs and configure the policy >> > enforcement point. >> >> Sure, that's essentially correct. >> The DNS proxy is just the local recursive resolver. >> What counts is that the MUD controller and the IoT device use the sa= me >> recursive resolver, and see the same cache. > Yes. > Also, I assume the IoT device won't do DNS lookup frequently, so > updating the cache each time when the IoT device sends the DNS query > can be acceptable. I agree that this would reduce the DNS lookup frequency. In the end, either strategy can work, as long as the IoT device can be convinced to always do DNS queries to a place that the MUD controller knows about. Updating the ACLs based upon DNS queries means that there has to be some new active entity in the DNS lookup path, and this may be much harder to deploy. For home gateways, it's all degenerate, so both methods are probably equivalent. For enteprises, it is not. DNS recursive services are something which enterprise operators tend to be reluctant to mess with, as it often have profound effects on the desktop us= er experience. =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+93Q3WUFAl9ssIoACgkQgItw+93Q 3WUGbAf7BKFAST/MoKfNNI3JkFLWF4C78XtkXzbYh9a8d6MQ+L51RqqlGeChoUt0 ObD8Etzw5dRjSKxNJ2FibnxMVqAjk2mp7YzGwNRstC77rm4+U1G8kVvl7WGU9YIC IkmFsPA+gKve5hwVbXzh808QzphztXdOl6BsqNEwC/QlCB8UvEK8w02Bv92HxANM Jv8kGmzDrKXlZs2cTUznCWUxuiM8II6hEbgFL+PmAcggFUsPY/AoPJ06kcshd2Ub tqvm3uQees7zbeezjmednATMq2wBa/gE1yJsxPZRt4O+J/ORyQ/aXnE8MkGPVcMj HIC7ouPEhunGZJz3F2hCtgw5ikwxpA== =QyKA -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 24 07:46:45 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01D3A0D47; Thu, 24 Sep 2020 07:46:40 -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 ZyovgcZZVUll; Thu, 24 Sep 2020 07:46:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0EE3A0A02; Thu, 24 Sep 2020 07:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 86BF9389B4; Thu, 24 Sep 2020 10:25:13 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fx8mn9JC-vU5; Thu, 24 Sep 2020 10:25:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A767C389B3; Thu, 24 Sep 2020 10:25:12 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 675D1824; Thu, 24 Sep 2020 10:46:36 -0400 (EDT) From: Michael Richardson To: Eliot Lear , opsawg , "mud\@ietf.org" In-Reply-To: References: <160082461405.2339.249127609152770744@ietfa.amsl.com> <16821.1600885661@localhost> 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: [Mud] [OPSAWG] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 14:46:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >> On 23 Sep 2020, at 20:27, Michael Richardson = wrote: >> >> Yes, the CPE could look at the DNS queries the device is using, and = then >> cache them. Or, when it loads the MUD file, it could do a DNS look= up on all >> the names, and cache them. Then, when the device asks, it is alread= y cached, >> and one can be sure that a known IP/name combination is returned. >> If it does this DNS lookup on a regular basis (updating the MUD ACLs >> implemented in the forwarding plane), then the cache stays warm, and= the >> rules are accurate. >> >> This is how our implementation worked. > Either this, or there should be a relationship between the resolver a= nd > the AP/switch/firewall/CPE in which appropriate query responses are > shared. That might be the better long term approach. So you are imagining some channel from the recursive DNS resolver(s) which basically just stream all name->IP pairs being cached. An MQTT channel or encrypted multicast or CoAP Observe. The policy enforcement point(s) would then be in charge of updating the ACLs that were installed with names. One could even hash the names into some number of channels if the update ra= te was otherwise too busy. > What is key- in > order for protection to work, the infrastructure needs to know (1) wh= at > names are authorized and (b) their associated addresses. As importan= t, > its understanding must be the same as that of the device that makes t= he > query. Yes. The common understanding of the mapping is key. =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+93Q3WUFAl9ssUwACgkQgItw+93Q 3WWMMAgAoqmgtelBFOFOOJxiQFyrmMXtDhJhmjswL4oSBmnsIQbFlXGazM2wehw6 7PLMGxu9+VXKb4SThNZxxOEKrMc7SH0jHjlh/zgSTmcmFHmJ/8X/Ai2XlvFFa+Pe XMbIBV9zgTGvsAXGZfMUsMkASMiU3Cp3DJ+UB26/QQ2x9mZzTSmGdZy6lmLro8RU wa9l6vrokOWUm3Pkj0rxr8pajg8BZSLwPdsowYFrC4gjUWCL6JFXwyLj/7ihHSen soCpSHoSXQjCrMBMGltghJ2Y8GAWAc2rVsmhGl63xBqaXbcS8spQPGlePw0PhfW6 jC7p2C4J2z4d1kMSFkiFt/o5B0w+sg== =7K6f -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 24 08:20:29 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7023A0E06; Thu, 24 Sep 2020 08:20:28 -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 jrgb69EOAwJO; Thu, 24 Sep 2020 08:20:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9282D3A0DE8; Thu, 24 Sep 2020 08:20:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ED2D1389B4; Thu, 24 Sep 2020 10:58:59 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rKTydgd3-trE; Thu, 24 Sep 2020 10:58:56 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ECE6438994; Thu, 24 Sep 2020 10:58:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 857014DB; Thu, 24 Sep 2020 11:20:19 -0400 (EDT) From: Michael Richardson To: opsawg@ietf.org, mud@ietf.org In-Reply-To: <160082461431.2339.6222888407127336620@ietfa.amsl.com> References: <160082461431.2339.6222888407127336620@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: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 15:20:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Another thread is active at: https://mailarchive.ietf.org/arch/msg/opsawg/04UY5rDs_oj= h97_edY-a4xBPZT4 I meant to wait to post this email until there had been some discussion abo= ut the acceptable-urls document. From=202018 onwards I have been working with CIRALabs on an IoT security sy= stem for home gateways. This first two revisions of the effort were very much M= UD focused, and this document was written to capture my experiences with DNS lookups vs MUD names in MUD files. This document was presented at the IETF107 virtual interim meeting in April. The slides are at: https://www.ietf.org/proceedings/interim-2020-opsawg-01/= slides/slides-interim-2020-opsawg-01-sessa-operational-considerations-for-u= se-of-dns-in-iot-devices-wslide-numbers-00 As a big part of the advice is to use the local resolver, whether via Do53, DoT or DoH, it was suggested that this advice might be better given by the Adaptive DNS Discovery (ADD). Perhaps that made more sense when it was the Applications Doing DNS BOF tho= ugh. A number of discussions about this document over the summer with the ADD chairs revealed that the document does not belong in the ADD WG. The -03 version contains mostly minor editorial changes. I've decided that, even as a BCP, that it seems to still be using BCP14 lan= guage, and so should include the boilerplate. I would like the OPSAWG to consider adopting this MUD related document. It changes no bits on the wire changes to MUD or semantic changes (like my other document), rather this is guidance to IoT manufacturers. Name: draft-richardson-opsawg-mud-iot-dns-considerations Revision: 03 Title: Operational Considerations for use of DNS in IoT devices Document date: 2020-09-22 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns= -considerations-03.txt Status: https://datatracker.ietf.org/doc/draft-richardson-opsawg-mu= d-iot-dns-considerations/ Html: https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns= -considerations-03.html Htmlized: https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot= -dns-considerations-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-richardson-opsawg= -mud-iot-dns-considerations-03 Abstract: This document details concerns about how Internet of Things devices use IP addresses and DNS names. The issue becomes acute as network operators begin deploying RFC8520 Manufacturer Usage Description (MUD) definitions to control device access. This document explains the problem through a series of examples of what can go wrong, and then provides some advice on how a device manufacturer can best make deal with these issues. The recommendations have an impact upon device and network protocol design. {RFC-EDITOR, please remove. Markdown and issue tracker for this document is at https://github.com/mcr/iot-mud-dns-considerations.git } =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+93Q3WUFAl9suTMACgkQgItw+93Q 3WUyfAf/bgNcvLIkY6PuDKAzCLY8KWG0Ka6lEKIyfIFBx/3P8RkDpJBT+VLE6Ann P9itB55Wmtp4QAYfDDsq0x/bu+BMztzHlVQlxPM0dYPmYM+82GwGzowz1O/0GgCx YhmhL3OnS99YNilZhUYx5sFeLXGfHyAACHM7yxf2cPnF6aAizoowf2lHiCs+QBjx eEb/6JjDK+9Fjvs6VlhZ8zO3mCX/ADPebh7Z6/TALueOBYvX4O3FD1XddovS9oWI qj8Oww7jn27ivUZYlwRRjSqc3XTgXbUn710u5g5wyDKYTzb8a+tk9tjqLns/qC9y aPs3SczjnzSQ2/x3inFWQaIHFFHwaw== =ocCF -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 24 09:23:55 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026AD3A105A; Thu, 24 Sep 2020 09:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-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 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 b-TILF5g1LhY; Thu, 24 Sep 2020 09:23:52 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FC93A1002; Thu, 24 Sep 2020 09:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1330; q=dns/txt; s=iport; t=1600964632; x=1602174232; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=2QMQGmobc3TH6hF5Nm3gEHtAUqHLY5nyke3Zsq9OcU4=; b=PCTXDCTQVxikfEbQJlo0urvVW78jooILJSiL6B2qv1VJ0sUb4Zzv+E3M 6kt2L+RHPdg5K8G2tRfQGtgCroVljhp8OD9aOvnJVZIJSdmoDevQyukzt cq9u/UOxRci7paJ3E0GUWMzW4HKuEn18LR9jaxOWbYm9MjtZFyDq1Lreg 4=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CBAADzxmxf/xbLJq1fGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBgg8Cg20BMiyEPIkCiEGcIQQHAQEBCgMBAS8EAQGESwKCLyU5B?= =?us-ascii?q?Q0CAwEBAQMCAwEBAQEFAQEBAgEGBG2FaIVyAQEBAQIBI1YFCwsYKgICVwYTg?= =?us-ascii?q?yYBglwgtkN2gTKFU4UIEIE4AYFSi3aCAIE4HIJNPodUM4ItBJAai1abR4Jxg?= =?us-ascii?q?xOBNZYNAx+CegGPHY51ryuDXAIEBgUCFYFsIoFXMxoIGxVlAYI+PhIZDZxoP?= =?us-ascii?q?wMwNwIGAQkBAQMJj3YBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,298,1596499200"; d="asc'?scan'208";a="27456618" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2020 16:23:48 +0000 Received: from [10.61.248.19] ([10.61.248.19]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 08OGNl5A016380 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Sep 2020 16:23:48 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_866B6D48-93F6-4454-99FA-19576FD4A667"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 24 Sep 2020 18:23:45 +0200 In-Reply-To: <15779.1600960819@localhost> Cc: opsawg@ietf.org, mud@ietf.org To: Michael Richardson References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.248.19, [10.61.248.19] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 16:23:54 -0000 --Apple-Mail=_866B6D48-93F6-4454-99FA-19576FD4A667 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Sep 2020, at 17:20, Michael Richardson = wrote: >=20 >=20 > I would like the OPSAWG to consider adopting this MUD related = document. > It changes no bits on the wire changes to MUD or semantic changes = (like my > other document), rather this is guidance to IoT manufacturers. >=20 I=E2=80=99d like that too. Eliot --Apple-Mail=_866B6D48-93F6-4454-99FA-19576FD4A667 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl9syBEACgkQh7ZrRtnS ejOUtQgA088D4VJS8aWQEfcNfQzNgiz+O/Ayx8by/Y0pnYALWnGI80M0NK5d5bTo p911Ex4k2V62mPSG9xfSWUG4A0jhnvpjZw+U2yVcD7SFcRASQNABhZFpT8OFkbpO yF42yogiheW7BfW7PgUK6sMDj2/LZb2ty7n/8TbjL3mWYiUTwJuS+GNWPXklOarT BcvNuQQjzhYDqOkts8SQt9TscnYOG4q40V+mfpZHIR7gTmwDfz0F+c3ivmFgbShw FAZEfsZYU0eP1CmpiwZVBLd8sZmJ3UcTZWTm5hULzlAgKTW4V2IgkGS8KECv/Zo4 fb/izA2LrelNL39RP67xxzkRVov+Pw== =MC82 -----END PGP SIGNATURE----- --Apple-Mail=_866B6D48-93F6-4454-99FA-19576FD4A667-- From nobody Thu Sep 24 09:46:06 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6F63A10DD; Thu, 24 Sep 2020 09:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.815 X-Spam-Level: X-Spam-Status: No, score=-3.815 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=canada.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 WIiC6EuloT7i; Thu, 24 Sep 2020 09:46:01 -0700 (PDT) Received: from mx2.canada.ca (mx2.canada.ca [205.193.214.105]) (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 CB8643A10A9; Thu, 24 Sep 2020 09:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=canada.ca; i=@canada.ca; q=dns/txt; s=mx2; t=1600965958; x=1632501958; h=from:to:cc:subject:date:references:in-reply-to: content-transfer-encoding:mime-version; bh=kVwInMPN3N8SjvRyB4dKtn8e8iOP/7f6nmtp9cFdU2Y=; b=DvCOsT/ZQrSnK873R7nr4LijVWllVDmcK595hodOax2hGtB7IZZoiubl cAAGgSTlIyYdwidcCDDi6MmkHLjaAZXewdvrL9K2s4g3DqQDSb3s6iOWc fMgTLkJbaRvKgAnrrmsVH5rJd8eoQ6p+herptoxhDjIIuBOJWcFt/Va5X JwenP3DYw/ue9PRmNhV7h4PyJnD7NGWocZ5qGF3ke5ci/xqzSPHgiOKJg zFID1GOXucFUrxFCrEq9bsTC4vFXaCbN9Hx4a+vXj01EYVlFS6w3DwLTX gFEIIBbb+Mr7WVNwXaaqVnnre1zJZpx40PscMaYD2zOqRSGbcAI523jFo g==; IronPort-SDR: W6b4+kmE9Z9iDSYyaW+6kJIT+H6SvKinCaQLSm1jNA6zSujWVVJKTRYLQ6M+Ajfg/9QfdCohmb gpjvtyfyXM557HAvsC5mGv3WKyJkAH9C5ZFftEQUTyWdi7c5Tw/NoV/nBcIOa/YPw7LtJdFyd8 XRoOl1Hf4CY71fJLqaglGxKHqI7vrvpZ3GoxI5CVoZv7PU6vS+Arw/kSRjelj4jGe9Zb51zP3c 6PKjt7dvYGizVf9bIKGznKmQsw3OOrG1qllbjIkcq8AC4LClUgzVZtqyU+pLpMA1mzctY5MgsX N+M= X-Time-IN: 24 Sep 2020 16:45:54 -0000 From: "Bentley, Taylor (IC)" To: Michael Richardson , "opsawg@ietf.org" , "mud@ietf.org" CC: "aiiotbd@intgovforum.org" Thread-Topic: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt Thread-Index: AQHWkoZKSRWOutXun0Gi9C4Rf5ewP6l3/HQg Date: Thu, 24 Sep 2020 16:45:49 +0000 References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> In-Reply-To: <15779.1600960819@localhost> Accept-Language: en-US Content-Language: en-US x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Message-Id: <20200924164557.CB8643A10A9@ietfa.amsl.com> Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 16:46:05 -0000 SGkgTWljaGFlbCwgYWxsLA0KDQpGYW50YXN0aWMgKGNvbnRpbnVlZCkgd29yayEgSXQncyBhIHBs ZWFzdXJlIHRvIGNvbnRpbnVlIGZvbGxvd2luZyBpbiBtb3JlLW9yLWxlc3MgcGVyc29uYWwgY2Fw YWNpdHkuIEluIHRoaXMgc2FtZSByb2xlIEkgYW0gZm9sbG93aW5nIHByZXBhcmF0aW9ucyBmb3Ig dGhlIGFubnVhbCBnbG9iYWwgSW50ZXJuZXQgR292ZXJuYW5jZSBGb3J1bSAoSUdGKSBhbmQgQ2Fu YWRpYW4gSW50ZXJuZXQgR292ZXJuYW5jZSBGb3J1bSAoQ0lHRikuIFRoaXMgaW5jbHVkZXMgZm9s bG93aW5nIHRoZSBpbnRlcnNlc3Npb25hbCBlZmZvcnRzIG9mIHRoZSBnbG9iYWwgSUdGJ3MgJ0Jl c3QgUHJhY3RpY2UgRm9ydW0gb24gRGF0YSBhbmQgTmV3IFRlY2hub2xvZ2llcy4nIFRoZXkgYXJl IHNlZWtpbmcgaW5wdXQgb24gaXNzdWVzIHRoYXQgTWljaGFlbCdzL0NJUkFMYWJzIHdvcmsgYW5k IHRoZXNlIGd1aWRlbGluZXMgZm9yIElvVCBtYW51ZmFjdHVyZXJzIHNlZW1zIHRvIGFsaWduIHdp dGguIEkgcmVjb21tZW5kIHdlIChhbmQgaW5kZWVkLCBoYXZlIGdvbmUgYWhlYWQgYW5kLCkgY29u bmVjdCB0aGUgZG90cyBvbiB0aGVzZSB0d28gZWZmb3J0cyBhbmQgcGVyaGFwcyB3ZSBjYW4gaGln aGxpZ2h0IHNvbWUgZ3JlYXQgd29yayBpbiBJKiBvcmdhbml6YXRpb25zIGluIHRoZSB3b3JrIG9m IHRoZSBJR0YgQlBGPw0KDQpUaGFua3MsDQoNClRheWxvciBSLlcuIEJlbnRsZXkNClRlbGVjb21t dW5pY2F0aW9ucyBhbmQgSW50ZXJuZXQgUG9saWN5IFNwZWNpYWxpc3QNCklubm92YXRpb24sIFNj aWVuY2UgYW5kIEVjb25vbWljIERldmVsb3BtZW50IENhbmFkYSAvIEdvdmVybm1lbnQgb2YgQ2Fu YWRhDQp0YXlsb3IuYmVudGxleUBjYW5hZGEuY2EgLyBUZWw6IDYxMy0yOTItOTk5OCAvIFRUWTog MS04NjYtNjk0LTgzODkgDQpTcMOpY2lhbGlzdGUgZGVzIHBvbGl0aXF1ZXMgZGUgdGVsZWNvbW11 bmljYXRpb25zIGV0IGQnSW50ZXJuZXQNCklubm92YXRpb24sIFNjaWVuY2VzIGV0IETDqXZlbG9w cGVtZW50IMOpY29ub21pcXVlIENhbmFkYSAvIEdvdXZlcm5lbWVudCBkdSBDYW5hZGENCnRheWxv ci5iZW50bGV5QGNhbmFkYS5jYSAvIFTDqWwuIDogNjEzLTI5Mi05OTk4IC8gQVRTIDogMS04NjYt Njk0LTgzODkNCg0KcC5zLi0tPg0KSGVyZSdzIHRoZSBjYWxsb3V0IGZyb20gdGhlIFVOU2VjIHN1 cHBvcnQgKHRydWx5IGV4Y2VwdGlvbmFsIGluZGl2aWR1YWxzKSBmb3IgdGhlIEJQRjogDQoNCkRl YXIgQWxsLCANCg0KVGhlIEJQRiBEYXRhIGFuZCBOZXcgVGVjaG5vbG9naWVzIGlzIGNvbGxlY3Rp bmcgZXhhbXBsZXMgb2YgaG93IHN0YWtlaG9sZGVycyBhZGRyZXNzIHRoZSBjaGFsbGVuZ2VzIHJl bGF0ZWQgdG8gY29sbGVjdGluZyBhbmQgdXNpbmcgdXNlcnPigJkgZGF0YS4gVGhlIGNhc2Ugc3R1 ZGllcyB3aWxsIGZlZWQgaW50byB0aGUgQlBGJ3MgZGlzY3Vzc2lvbnMgYW5kIGl0cyB3b3Jrc2hv cCBhcyBwYXJ0IG9mIHRoZSBJR0YgMjAyMCBpbnRlcnNlc3Npb25hbCB3b3JrIGFuZCB0aGUgdmly dHVhbCBJR0YyMDIwIG1lZXRpbmcgaW4gTm92ZW1iZXIuIA0KDQpUaGUgQlBGIGlzIGludGVyZXN0 ZWQgaW4gZXhhbXBsZXMgb2YgDQrigKIJYXBwbGljYXRpb25zIChkZXBsb3llZCBvciB1bmRlciBk ZXZlbG9wbWVudCkgdGhhdCB1c2UgdXNlcnPigJkgZGF0YSB0byBwcm92aWRlIGJlbmVmaXQgdG8g dGhlIHVzZXIsIGFuZCB0aGUgbWVhc3VyZXMgdGhhdCBzaG91bGQgYXZvaWQgdGhhdCB0aGUgY29s bGVjdGVkIGRhdGEgbWF5IGJlIHVzZWQgdG8gaGFybXMgdGhlIHVzZXJzLg0K4oCiCWZyYW1ld29y a3MsIGd1aWRlbGluZXMsIGFuZCBwb2xpY2llcyB0aGF0IGFkZHJlc3MgY2hhbGxlbmdlcyBhbmQg YWltIHRvIGVuc3VyZSB0aGF0IHVzZXJzIHdob3NlIGRhdGEgaXMgYmVpbmcgY29sbGVjdGVkIGFu ZCB1c2VkLCBjYW4gYmVuZWZpdCBmcm9tIHRoZWlyIGRhdGEgYW5kIGRvIG5vdCByaXNrIHRvIGJl IGhhcm1lZC4gDQoNClRoZSBCUEYgaXMgaW50ZXJlc3RlZCBpbiBjYXNlIHN0dWRpZXMgdGhhdCBh cmUgcmVsYXRlZCBhcyB3ZWxsIGFzIHVucmVsYXRlZCB0byB0aGUgQ09WSUQtMTkgcGFuZGVtaWMu ICAgDQoNCkRldGFpbHMgb24gdGhlIGNhbGwgZm9yIGNvbnRyaWJ1dGlvbnMgY2FuIGJlIGZvdW5k IGhlcmUgaHR0cHM6Ly93d3cuaW50Z292Zm9ydW0ub3JnL211bHRpbGluZ3VhbC9jb250ZW50L2Jw Zi1kYXRhLW5ldy10ZWNobm9sb2dpZXMtY2FzZS1zdHVkaWVzIC4gDQoNCldlIHdvdWxkIGFwcHJl Y2lhdGUgdG8gcmVjZWl2ZSB5b3VyIGNhc2Ugc3R1ZHkgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsg LSBGcmlkYXkgMjUgU2VwdGVtYmVyLg0KDQpJbiBwcmVwYXJhdGlvbiBvZiB0aGUgY2FsbCBmb3Ig Y29udHJpYnV0aW9ucywgdGhlIEJQRiBkaXNjdXNzZWQgd2hhdCBjb3VsZCBiZSBwb3RlbnRpYWwg aXNzdWVzIGFuZCBwdXQgdGhlbSB0b2dldGhlciBpbiBhIOKAmERhdGEgYW5kIE5ldyBUZWNobm9s b2dpZXMgSXNzdWVzIGNhcmTigJkuIFRoZSBpc3N1ZXMgY2FyZCBjYW4gaGVscCB3aXRoIHB1dHRp bmcgdG9nZXRoZXIgYSBjYXNlIHN0dWR5Lg0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNl IGNoZWNrIHRoZSBCUEYgRGF0YSBhbmQgTmV3IFRlY2hub2xvZ2llcyB3ZWJwYWdlLg0KDQpLaW5k IFJlZ2FyZHMNCg0KVGhlIEJQRiBEYXRhIGFuZCBOZXcgVGVjaG5vbG9naWVzIGNvb3JkaW5hdGlu ZyB0ZWFtLA0KVGl0dGksIEVtYW51ZWxhLCBXaW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE11ZCA8bXVkLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaWNoYWVs IFJpY2hhcmRzb24NClNlbnQ6IFNlcHRlbWJlciAyNCwgMjAyMCAxMToyMCBBTQ0KVG86IG9wc2F3 Z0BpZXRmLm9yZzsgbXVkQGlldGYub3JnDQpTdWJqZWN0OiBbTXVkXSBjaGFuZ2VzIHRvIGRyYWZ0 LXJpY2hhcmRzb24tb3BzYXdnLW11ZC1pb3QtZG5zLWNvbnNpZGVyYXRpb25zLTAzLnR4dA0KDQoN CkFub3RoZXIgdGhyZWFkIGlzDQogICAgICAgIGFjdGl2ZSBhdDogaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9vcHNhd2cvMDRVWTVyRHNfb2poOTdfZWRZLWE0eEJQWlQ0DQoN CkkgbWVhbnQgdG8gd2FpdCB0byBwb3N0IHRoaXMgZW1haWwgdW50aWwgdGhlcmUgaGFkIGJlZW4g c29tZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBhY2NlcHRhYmxlLXVybHMgZG9jdW1lbnQuDQoNCkZy b20gMjAxOCBvbndhcmRzIEkgaGF2ZSBiZWVuIHdvcmtpbmcgd2l0aCBDSVJBTGFicyBvbiBhbiBJ b1Qgc2VjdXJpdHkgc3lzdGVtIGZvciBob21lIGdhdGV3YXlzLiAgVGhpcyBmaXJzdCB0d28gcmV2 aXNpb25zIG9mIHRoZSBlZmZvcnQgd2VyZSB2ZXJ5IG11Y2ggTVVEIGZvY3VzZWQsIGFuZCB0aGlz IGRvY3VtZW50IHdhcyB3cml0dGVuIHRvIGNhcHR1cmUgbXkgZXhwZXJpZW5jZXMgd2l0aCBETlMg bG9va3VwcyB2cyBNVUQgbmFtZXMgaW4gTVVEIGZpbGVzLg0KDQpUaGlzIGRvY3VtZW50IHdhcyBw cmVzZW50ZWQgYXQgdGhlIElFVEYxMDcgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgaW4gQXByaWwu DQpUaGUgc2xpZGVzIGFyZSBhdDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50 ZXJpbS0yMDIwLW9wc2F3Zy0wMS9zbGlkZXMvc2xpZGVzLWludGVyaW0tMjAyMC1vcHNhd2ctMDEt c2Vzc2Etb3BlcmF0aW9uYWwtY29uc2lkZXJhdGlvbnMtZm9yLXVzZS1vZi1kbnMtaW4taW90LWRl dmljZXMtd3NsaWRlLW51bWJlcnMtMDANCg0KQXMgYSBiaWcgcGFydCBvZiB0aGUgYWR2aWNlIGlz IHRvIHVzZSB0aGUgbG9jYWwgcmVzb2x2ZXIsIHdoZXRoZXIgdmlhIERvNTMsIERvVCBvciBEb0gs IGl0IHdhcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGFkdmljZSBtaWdodCBiZSBiZXR0ZXIgZ2l2ZW4g YnkgdGhlIEFkYXB0aXZlIEROUyBEaXNjb3ZlcnkgKEFERCkuDQoNClBlcmhhcHMgdGhhdCBtYWRl IG1vcmUgc2Vuc2Ugd2hlbiBpdCB3YXMgdGhlIEFwcGxpY2F0aW9ucyBEb2luZyBETlMgQk9GIHRo b3VnaC4NCkEgbnVtYmVyIG9mIGRpc2N1c3Npb25zIGFib3V0IHRoaXMgZG9jdW1lbnQgb3ZlciB0 aGUgc3VtbWVyIHdpdGggdGhlIEFERCBjaGFpcnMgcmV2ZWFsZWQgdGhhdCB0aGUgZG9jdW1lbnQg ZG9lcyBub3QgYmVsb25nIGluIHRoZSBBREQgV0cuDQoNClRoZSAtMDMgdmVyc2lvbiBjb250YWlu cyBtb3N0bHkgbWlub3IgZWRpdG9yaWFsIGNoYW5nZXMuDQpJJ3ZlIGRlY2lkZWQgdGhhdCwgZXZl biBhcyBhIEJDUCwgdGhhdCBpdCBzZWVtcyB0byBzdGlsbCBiZSB1c2luZyBCQ1AxNCBsYW5ndWFn ZSwgYW5kIHNvIHNob3VsZCBpbmNsdWRlIHRoZSBib2lsZXJwbGF0ZS4NCg0KSSB3b3VsZCBsaWtl IHRoZSBPUFNBV0cgdG8gY29uc2lkZXIgYWRvcHRpbmcgdGhpcyBNVUQgcmVsYXRlZCBkb2N1bWVu dC4NCkl0IGNoYW5nZXMgbm8gYml0cyBvbiB0aGUgd2lyZSBjaGFuZ2VzIHRvIE1VRCBvciBzZW1h bnRpYyBjaGFuZ2VzIChsaWtlIG15IG90aGVyIGRvY3VtZW50KSwgcmF0aGVyIHRoaXMgaXMgZ3Vp ZGFuY2UgdG8gSW9UIG1hbnVmYWN0dXJlcnMuDQoNCg0KTmFtZToJCWRyYWZ0LXJpY2hhcmRzb24t b3BzYXdnLW11ZC1pb3QtZG5zLWNvbnNpZGVyYXRpb25zDQpSZXZpc2lvbjoJMDMNClRpdGxlOgkJ T3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMgZm9yIHVzZSBvZiBETlMgaW4gSW9UIGRldmljZXMN CkRvY3VtZW50IGRhdGU6CTIwMjAtMDktMjINCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTEzDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtcmljaGFyZHNvbi1vcHNhd2ctbXVkLWlvdC1kbnMtY29uc2lkZXJhdGlvbnMtMDMudHh0DQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmlj aGFyZHNvbi1vcHNhd2ctbXVkLWlvdC1kbnMtY29uc2lkZXJhdGlvbnMvDQpIdG1sOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcmljaGFyZHNvbi1vcHNhd2ctbXVkLWlv dC1kbnMtY29uc2lkZXJhdGlvbnMtMDMuaHRtbA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoYXJkc29uLW9wc2F3Zy1tdWQtaW90LWRucy1jb25z aWRlcmF0aW9ucy0wMw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1yaWNoYXJkc29uLW9wc2F3Zy1tdWQtaW90LWRucy1jb25zaWRlcmF0aW9u cy0wMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGV0YWlscyBjb25jZXJucyBhYm91 dCBob3cgSW50ZXJuZXQgb2YgVGhpbmdzIGRldmljZXMNCiAgIHVzZSBJUCBhZGRyZXNzZXMgYW5k IEROUyBuYW1lcy4gIFRoZSBpc3N1ZSBiZWNvbWVzIGFjdXRlIGFzIG5ldHdvcmsNCiAgIG9wZXJh dG9ycyBiZWdpbiBkZXBsb3lpbmcgUkZDODUyMCBNYW51ZmFjdHVyZXIgVXNhZ2UgRGVzY3JpcHRp b24NCiAgIChNVUQpIGRlZmluaXRpb25zIHRvIGNvbnRyb2wgZGV2aWNlIGFjY2Vzcy4NCg0KICAg VGhpcyBkb2N1bWVudCBleHBsYWlucyB0aGUgcHJvYmxlbSB0aHJvdWdoIGEgc2VyaWVzIG9mIGV4 YW1wbGVzIG9mDQogICB3aGF0IGNhbiBnbyB3cm9uZywgYW5kIHRoZW4gcHJvdmlkZXMgc29tZSBh ZHZpY2Ugb24gaG93IGEgZGV2aWNlDQogICBtYW51ZmFjdHVyZXIgY2FuIGJlc3QgbWFrZSBkZWFs IHdpdGggdGhlc2UgaXNzdWVzLiAgVGhlDQogICByZWNvbW1lbmRhdGlvbnMgaGF2ZSBhbiBpbXBh Y3QgdXBvbiBkZXZpY2UgYW5kIG5ldHdvcmsgcHJvdG9jb2wNCiAgIGRlc2lnbi4NCg0KICAge1JG Qy1FRElUT1IsIHBsZWFzZSByZW1vdmUuICBNYXJrZG93biBhbmQgaXNzdWUgdHJhY2tlciBmb3Ig dGhpcw0KICAgZG9jdW1lbnQgaXMgYXQgaHR0cHM6Ly9naXRodWIuY29tL21jci9pb3QtbXVkLWRu cy1jb25zaWRlcmF0aW9ucy5naXQNCiAgIH0NCg0KDQoNCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNv biA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRpbmcg KQ0KICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdv cmxkd2lkZQ0KDQoNCg0KDQo= From nobody Thu Sep 24 10:44:21 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAB63A11DD; Thu, 24 Sep 2020 10:44:18 -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 2f5Gw1Lz_CXg; Thu, 24 Sep 2020 10:44:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043043A11CC; Thu, 24 Sep 2020 10:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ECAAE389BD; Thu, 24 Sep 2020 13:22:40 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K5svNG6TnmQ8; Thu, 24 Sep 2020 13:22:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E70C389B4; Thu, 24 Sep 2020 13:22:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 64BD84DB; Thu, 24 Sep 2020 13:43:54 -0400 (EDT) From: Michael Richardson To: Qin Wu , "mud\@ietf.org" , "iot-onboarding\@ietf.org" In-Reply-To: References: 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: [Mud] [Iot-onboarding] administrative control of devices --- thinking again about an IoT security WG X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 17:44:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Qin Wu wrote: > Have we considered to manage multiple devices on boarding at one time? > These devices might be placed behind the same gateway device. In some > cases, there is no DNS infrastructure or DHCP. BRSKI and the 802.1X EAP methods (EAP-NOOB, BRSKI-TEAP) do not need DHCP or DNS in order to onboard devices. Multiple devices is not more difficult than a single device. I had some contact with some Google IoT people who were considering how a home owner might onboard dozens to hundreds of devices. Consider a person who has just moved into a new apartment, or installers setting up an office building. The issue primarily about be sure that the device in your "hand" is actually the device being controlled. Given a mess of boxes on the floor, even NFC could see many devices. There is an advantage to having an integrated API, because one can make the device "do" something to confirm it's the right device. That's a bit of slippery slope of APIs, but "identify self" is a reasonable administrative API that could be in common. (Some 1U servers have a blue LED with a button just so that you match the front/back of a given 1U server in a cabinet full of ~48 of them... Some versions could also turn this on via software, or can query the state of the button via software) =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+93Q3WUFAl9s2toACgkQgItw+93Q 3WW8Agf9GbvhS79zoromDnMRwu90lhJbahdlXYsPJEg5kb+IbANgI/4TGBhs1IcO ZP0StOMMAJ0iu5aYU4RzDiSLzC3z7ZupcjGqz9fUrfdLbWo4oJSt6wQcRdZ1P6tU B/GcZcSEXtdMWjD9ZVBuNUldExMafxqPRrak8vV/3keY8FG5CT5ALHD1PouXu44s u8kfCdHFTmdRDpue0Ry5woDNDrv6jSXFADH57bpWzDvedHmnzQf2cqz6qOt/CxXV OdkmGXNkFawgqPYq/G043f7uSd6y0iey8i060Bu50MWGK38Gg2OURhENrqXtGqdO UniVP7ZjTUdoPsodtHHQJ9CzJgGJ8g== =YyQn -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 25 01:16:48 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C973A129D; Fri, 25 Sep 2020 01:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkQjg4BrICRg; Fri, 25 Sep 2020 01:16:45 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 80D103A129A; Fri, 25 Sep 2020 01:16:45 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id y74so1774238iof.12; Fri, 25 Sep 2020 01:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a6nkuWjpMoYVAsYBvb3b+yWowde+giPW3docOCKHNLE=; b=UguMlLkbEJJ5cHjiP8uMY47GgrtAe5EzRoOTaACJiccDjqNENOG+of5jro2HcfUIEH hmbW/rG7NSZVcLZvj44OkoLe3OPmVTs1x6x0xxfBE2u6dBEPr1iGQc74cNiIWiIst8FC Dt1OrMgqTs7Md+IB7FWIFCIp9UDUqrzbe0nypYtUWWT5+UZqtj73L898q38mccdvEZ2j 5+ih9FTqQSXbL2TSibdm7kohmDZHa1k9p0D2o0dZAGziOYG0MHd5mgzvbuLQ4a4w/iFb st27lQnxLX8SWz7H1CsHIzP9EFXUfI/18QiAGTIK1PTTfY9cyyERqpxzTnX6LXEB4ucE jvgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a6nkuWjpMoYVAsYBvb3b+yWowde+giPW3docOCKHNLE=; b=DPT2uKVMKZDoVGKW/V0F2vsWEMQceSu0VdTKGDLc+ADmurk3UubWwcKSOw66BqbOPn kW1squXdtJO95gDPm6nVD1QUIBJeXGlaB1baJ0m/810Yj6exkmBsxvvDlZvX4qSvN0Nu z2L9jUjqUVDKxNjIPJ6lHMfgTgqS7q2uoJ9BtnOT428USuFPyAvKmUNpQv3HTClSdzaL gm+dWUor4/55Y41y66b88MR0mhjtuJaIBUyoSktU6KwLaVqPvguUQbcCgVEGW4VOFtyJ JsdR4qUcHTvo1Ld0ombPiLYF1o/iKJ0hsfI+8MOa6ghAFBdRQwD3oA5eOhQig0XGhw70 g0Vg== X-Gm-Message-State: AOAM533Uu7Q+wfT+UtGH8KXe/OJFmJSd0ERBghrDMCg7OJCtStDSL5SZ 9qfRlzC3555PSjg5kbh17zQzysCjY5hxqbMwLyX5iBwqqOmBWw== X-Google-Smtp-Source: ABdhPJxf6HS/IkGkdIWHNG7arCcAAdALgDhbKpMfviaolCL8M/sSWUbcoiJvbxY6l6DQdUl0sjGPYepsCQCRonJsZi4= X-Received: by 2002:a02:8802:: with SMTP id r2mr2398590jai.75.1601021804626; Fri, 25 Sep 2020 01:16:44 -0700 (PDT) MIME-Version: 1.0 References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> In-Reply-To: From: tirumal reddy Date: Fri, 25 Sep 2020 13:46:33 +0530 Message-ID: To: Eliot Lear Cc: Michael Richardson , opsawg , mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000f145f405b01eef41" Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 08:16:47 -0000 --000000000000f145f405b01eef41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1. The problem is not just with public resolvers but also with designated resolvers. The IoT device supporting MUD must use the encrypted DNS server discovered in the attached network. -Tiru On Thu, 24 Sep 2020 at 21:53, Eliot Lear wrote: > > > > On 24 Sep 2020, at 17:20, Michael Richardson > wrote: > > > > > > I would like the OPSAWG to consider adopting this MUD related document. > > It changes no bits on the wire changes to MUD or semantic changes (like > my > > other document), rather this is guidance to IoT manufacturers. > > > > I=E2=80=99d like that too. > > Eliot > > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > --000000000000f145f405b01eef41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1.=C2=A0
The problem is not just with publ= ic resolvers but also with designated resolvers. The IoT device supporting = MUD must use the encrypted DNS server discovered in the attached network.

-Tiru

On Thu, 24 Sep 2020 at 21:5= 3, Eliot Lear <lear=3D40ci= sco.com@dmarc.ietf.org> wrote:


> On 24 Sep 2020, at 17:20, Michael Richardson <mcr+ietf@sandelman.ca> wrote= :
>
>
> I would like the OPSAWG to consider adopting this MUD related document= .
> It changes no bits on the wire changes to MUD or semantic changes (lik= e my
> other document), rather this is guidance to IoT manufacturers.
>

I=E2=80=99d like that too.

Eliot

--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud
--000000000000f145f405b01eef41-- From nobody Fri Sep 25 10:41:55 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AA83A1091; Fri, 25 Sep 2020 10:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXS8Z3HsNarv; Fri, 25 Sep 2020 10:41:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF493A1080; Fri, 25 Sep 2020 10:41:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CC0323899F; Fri, 25 Sep 2020 13:20:22 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vA3uOYUXdcvP; Fri, 25 Sep 2020 13:20:21 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 801573899E; Fri, 25 Sep 2020 13:20:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 343734BB; Fri, 25 Sep 2020 13:41:46 -0400 (EDT) From: Michael Richardson To: tirumal reddy , Eliot Lear , opsawg , mud@ietf.org In-Reply-To: References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> 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: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 17:41:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tirumal reddy wrote: > +1. The problem is not just with public resolvers but also with > designated resolvers. The IoT device supporting MUD must use the > encrypted DNS server discovered in the attached network. Yes-ish. I don't think that we have to mandate use of encrypted DNS servers, as long as it's the ones on the attached network. My take is that it is better to use Do53 across the local LAN than public D= oH server. If the IoT device can be convinced to use the local DoT server, g= reat. But, your documents in ADD are clearly trying to get there, but we aren't there yet. I've been looking for a YANG module that would allow for explicit management of "/etc/resolv.conf" on a device. If there is one, I don't know where it would be. =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+93Q3WUFAl9uK9kACgkQgItw+93Q 3WU04Qf+Ki+jkfmyajlxSOQOQorS9CipT1oLyVnY3GatZ94gHUnLdEKy5upceHQr 8f5UrTsgaCOfPrvVlPkHr7/8e+X/zFhne/dtoRpyijRYz+leHoyeJbEEvzkv9k/J d3j2d45ev58hxZIIAPerkkgSemp7OXWsQ0GOzmR1cXWcn1KQQJ2SV7lB80dKIHfL 6wJxkDSwzPHk61hCUWukBIUGcZa3tCOVvIUtee3VxcfnEBmBvRUqZ/qLhKFIG0SN 3j5i9xMt1xxphAmeBHKDcczrTN3i9BOIuQTEPGQ2qPc6rMlmmcDXbG3aTj6H45sW Uvlwtk99HSZ6jDwt5T0dvVnAUs95tQ== =SJWb -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Sep 26 00:39:41 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328913A10FA; Sat, 26 Sep 2020 00:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7Zn-YwzGGBc; Sat, 26 Sep 2020 00:39:33 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A7D3A10E8; Sat, 26 Sep 2020 00:39:33 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id g7so5851145iov.13; Sat, 26 Sep 2020 00:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NOffToEETWiKgflvWxwiOcpJyBIACIW1P+zA6yyCaao=; b=jEowS07KO7hgWSUVLfJDHEq7IVtVGzbQrhxYK+Ea67lKqydTz8HzdRB81CD9nim4PL i93vLc8lh+O1C4QzKvnmrVrZljG4nNwpn06gcXd1PJBLdyUCNjbemV/54eKvq631/U1c S4U4QGX/N1seF6x29jaU9PXey+epN/qLlqNo/QOahY2VO8GBujLvCeETJB0dThacjflT t9zmkt+ZBnKyCmHk7ccFAWK4+Q5oG3bJGxKuwOrdlHh0HonMqP4Q7VqfuTN6xjROoll+ yIqIAT7dYr99Zo7eRR0z1gKpKQbBFPkvFBkoszJgoY0x4dQIL1vY/SGspU2xcSIY7pGB D/dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NOffToEETWiKgflvWxwiOcpJyBIACIW1P+zA6yyCaao=; b=hiX0tVjLNDMySl4kd7VGKGy/IIRuZHi0CP4DQihbEA/Yccg5Mj2S4OhRzKS9AdcSKY 4pVXL4MbCKZT7/EesDy/t7LlylPNg8ihsl3mp31bVGAjRbjD0ktzTcg+qrCaAtSMW3Nn P14Y7xeakkORaJGvkhC+4nNPEwLWhKUebABraplNJN5Ag7cCn+qO09ZZciDuFOuEvmx4 rFDSt90dsvcbn236KUzeuQKdutmCEovOgn/O+F1Ns7/ANR0F61EZeZFYAZ5JAxO//ahC Sqg5SfVccWJrWUdPqmQ29fVH8KLvmmisag1N19BXl4kaaonU+duxEl73vwgo7t2H3xSg JiUQ== X-Gm-Message-State: AOAM531D3xlD7ymE7C4Crwmxm9P59sJtfNgunzqHlnRauAy7iNeGF97F CZAI20l+pfgA9EkQvkV6pkVF35yQve2BZxCJyvF35VZjbkF+innN X-Google-Smtp-Source: ABdhPJydXO8gGMRytX/HAeVAycqZhgB58pgJWJlnPHz7afgDH6GZ31zpVeSPLUh0l8zJv3D9FQcCpFuZLeb7aX1/DoI= X-Received: by 2002:a6b:d908:: with SMTP id r8mr1577747ioc.21.1601105972764; Sat, 26 Sep 2020 00:39:32 -0700 (PDT) MIME-Version: 1.0 References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> In-Reply-To: <15491.1601055706@localhost> From: tirumal reddy Date: Sat, 26 Sep 2020 13:09:21 +0530 Message-ID: To: Michael Richardson Cc: Eliot Lear , opsawg , mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000c1271f05b032885e" Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 07:39:35 -0000 --000000000000c1271f05b032885e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 25 Sep 2020 at 23:11, Michael Richardson wrote: > > tirumal reddy wrote: > > +1. The problem is not just with public resolvers but also with > > designated resolvers. The IoT device supporting MUD must use the > > encrypted DNS server discovered in the attached network. > > Yes-ish. > > I don't think that we have to mandate use of encrypted DNS servers, > as long as it's the ones on the attached network. > In the home network use case, if the CPE does not support an encrypted DNS forwarder, endpoint will discover and use the ISP encrypted DNS recursive server. The CPE will no longer be able to enforce MUD rules. For instance, Firefox can discover and use Comcast Encrypted DNS recursive server, see https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html. > > My take is that it is better to use Do53 across the local LAN than public > DoH > server. If the IoT device can be convinced to use the local DoT server, > great. > But, your documents in ADD are clearly trying to get there, but we aren't > there yet. > In the interim ADD session 2, the consensus is to use DHCP/RA to discover the local encrypted DNS server. https://tools.ietf.org/html/draft-btw-add-home-09 extends DHCP/RA and it also discusses hosting a DoH/DoT forwarder on the home router. -Tiru > > I've been looking for a YANG module that would allow for explicit > management > of "/etc/resolv.conf" on a device. If there is one, I don't know where i= t > would be. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > --000000000000c1271f05b032885e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, 25 Sep 2020 at 23:11, Michael Ric= hardson <mcr+ietf@sandelman.c= a> wrote:

tirumal reddy <ko= ndtir@gmail.com> wrote:
=C2=A0 =C2=A0 > +1.=C2=A0 The problem is not just with public resolvers = but also with
=C2=A0 =C2=A0 > designated resolvers. The IoT device supporting MUD must= use the
=C2=A0 =C2=A0 > encrypted DNS server discovered in the attached network.=

Yes-ish.

I don't think that we have to mandate use of encrypted DNS servers,
as long as it's the ones on the attached network.
=
In the home network use case, if the CPE does not support an= encrypted DNS forwarder, endpoint will discover and use the ISP encrypted = DNS recursive server. The CPE will no longer be able to enforce MUD rules. = For instance, Firefox can discover and use Comcast Encrypted DNS recursive = server, see=C2=A0https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html.=C2=A0

My take is that it is better to use Do53 across the local LAN than public D= oH
server.=C2=A0 =C2=A0If the IoT device can be convinced to use the local DoT= server, great.
But, your documents in ADD are clearly trying to get there, but we aren'= ;t
there yet.


=
-Tiru
=C2=A0

I've been looking for a YANG module that would allow for explicit manag= ement
of "/etc/resolv.conf" on a device.=C2=A0 If there is one, I don&#= 39;t know where it
would be.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
--000000000000c1271f05b032885e-- From nobody Sat Sep 26 02:09:40 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F7A3A11A0; Sat, 26 Sep 2020 02:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 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 iX21Zh9qFaZ6; Sat, 26 Sep 2020 02:09:37 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032FB3A119D; Sat, 26 Sep 2020 02:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3392; q=dns/txt; s=iport; t=1601111377; x=1602320977; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=41qRtIs96/FXwafzSoTWqGvp2X5eMy48bIPNcdHWk6A=; b=Y7folHSM/nNPjoL5WUCRxrOMoEpY6jMuOpQlR1I2lSfUQafOKDDcruHh tI8XsBxYYmNsisdtWtWS8QAxYXJZNhYJ8GcusOC+iWczi2pokqCTjnHp1 bbj0exlK76OXbwR32OR1ogkdA5UbwvHJETkF8cRynNplB3/ns0FJu71gK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2BAD+BG9f/xbLJq1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU8CgSGBB3BVASASLI0+iEWKDol6iBkLAQEBDQEBIwwEAQG?= =?us-ascii?q?ESwKCLyY5BQ0CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgF5BQsLBBQuITY?= =?us-ascii?q?GE4MmAYJLAw4gD7VedIE0hVOCaA2CHgaBOAGNEDiCAIE4HIJNPoIaQgIBAoF?= =?us-ascii?q?Eg2KCLQS2bVGCcYMThWiMU4UJAx+hEp1vgmqOXINdAgQGBQIVgWwigVczGgg?= =?us-ascii?q?bFWUBgj4+EhkNlySFRD8DMAI1AgYKAQEDCY91AQE?= X-IronPort-AV: E=Sophos; i="5.77,305,1596499200"; d="scan'208,217"; a="29868956" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Sep 2020 09:09:33 +0000 Received: from dhcp-10-61-108-189.cisco.com (dhcp-10-61-108-189.cisco.com [10.61.108.189]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 08Q99WMb010786 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Sep 2020 09:09:32 GMT From: Eliot Lear Message-Id: <01E82C2E-1F3E-49AD-B900-45B3F834A127@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E370867F-0312-4E46-9D1A-08260B802D10" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 26 Sep 2020 11:09:32 +0200 In-Reply-To: Cc: Michael Richardson , opsawg , mud@ietf.org To: tirumal reddy References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.108.189, dhcp-10-61-108-189.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 09:09:39 -0000 --Apple-Mail=_E370867F-0312-4E46-9D1A-08260B802D10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tiru > On 26 Sep 2020, at 09:39, tirumal reddy wrote: >=20 > In the home network use case, if the CPE does not support an encrypted = DNS forwarder, endpoint will discover and use the ISP encrypted DNS = recursive server. The CPE will no longer be able to enforce MUD rules. = For instance, Firefox can discover and use Comcast Encrypted DNS = recursive server, see = https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html = .=20 Not necessarily. That is a matter of signaling between the CPE and the = ISP. Eliot= --Apple-Mail=_E370867F-0312-4E46-9D1A-08260B802D10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Tiru

On 26 Sep 2020, at 09:39, tirumal reddy = <kondtir@gmail.com> wrote:

In the home network use case, if = the CPE does not support an encrypted DNS forwarder, endpoint will = discover and use the ISP encrypted DNS recursive server. The CPE will no = longer be able to enforce MUD rules. For instance, Firefox can discover = and use Comcast Encrypted DNS recursive server, see https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html= . 


Not necessarily. =  That is a matter of signaling between the CPE and the = ISP.

Eliot
= --Apple-Mail=_E370867F-0312-4E46-9D1A-08260B802D10-- From nobody Sat Sep 26 16:03:01 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B98E3A0BDF; Sat, 26 Sep 2020 16:02:55 -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 GEOy1mkSCJHD; Sat, 26 Sep 2020 16:02:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB80C3A0A26; Sat, 26 Sep 2020 16:02:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4148A389A2; Sat, 26 Sep 2020 18:41:22 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qWv1eZYbd7H2; Sat, 26 Sep 2020 18:41:12 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F17AD3899E; Sat, 26 Sep 2020 18:41:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BCC7075; Sat, 26 Sep 2020 19:02:37 -0400 (EDT) From: Michael Richardson To: tirumal reddy , opsawg , mud@ietf.org, Eliot Lear In-Reply-To: References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> 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: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 23:02:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tirumal reddy wrote: >> tirumal reddy wrote: >> > +1. The problem is not just with public resolvers but also with >> > designated resolvers. The IoT device supporting MUD must use the >> > encrypted DNS server discovered in the attached network. >> >> Yes-ish. >> >> I don't think that we have to mandate use of encrypted DNS servers, >> as long as it's the ones on the attached network. >> > In the home network use case, if the CPE does not support an encrypte= d DNS > forwarder, endpoint will discover and use the ISP encrypted DNS recur= sive > server. The CPE will no longer be able to enforce MUD rules. For inst= ance, > Firefox can discover and use Comcast Encrypted DNS recursive server, = see > https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html. It's reasonable that Firefox might do that, but I don't see why IoT devices should follow suit, and that's the point of this document. Except in some very niche digital signage and kiosk use, I don't think a MUD file would be appropriate for a general-purpose browser. =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+93Q3WUFAl9vyI0ACgkQgItw+93Q 3WXLbgf+J4DsORfFUv56E77Hr6sz25Rh84rtuOzqtaQ05gUZZmHMIhDcHzmVRlJL q5qnmH4JCuzUFu4TwfQJrhgMKFXbdpVqw4F4w9fcLVA87Awi2YCRpTyWXO1RLF1V 6UlY7fnuPymULP42yGNY14aiqDJeAFcqLumovg/GPGZmI+n5DiZqC1GiKpFtJiYV H4OzEWVzEoklZTSR2h4er2PA6QiRSi+yyH5248UNm+8TVUbuTs7xeo/ExdmKKWiQ QUPk8v8ysF14p2CZswHMee/gghXBWdPCUWAEMj8mgmTOlNDk1hzHm6PG3A+wAM5t p4aGAuvZsn8rjvLRsbwoxPnuPtUFGA== =C+FW -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 27 23:52:55 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158AD3A0E99; Sun, 27 Sep 2020 23:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-Ymnhv_C5da; Sun, 27 Sep 2020 23:52:49 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 B44C73A0E83; Sun, 27 Sep 2020 23:52:49 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id g7so3681iov.13; Sun, 27 Sep 2020 23:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7wkEecOGBIx4MSTEg9IkfFASiIs9k/DtAoN1xO+4vUc=; b=WDjlKM4c9kA5heBq6TaSkZP5QV4sz+FvKvcp/6H2Kjt/5ocecbgIjpqtj98xgxYzp8 2r4Wzyk+Ch/GcDYHfW57Z5S03DzM9U0LtLXMwnyyZ2I5jEExEGL2KC8XTq0dY0JlU5tv dqYmKdQvVIfQGOud6bqlbgc1f6TJ6evjI7/trY4QTHcPaKlKfaoM9S+/c0yo7YLxuS8i 0/CHWLIsUj6x5vXYjMFxLrM8HtjxvTKif71J4gIoYkspUDsHn/wMpwlppTo6atH/B+Gv quGaqmeh8iTlgoQdsgP/e2c9g353uFkd0aXM/TMK3KRCMc4sifncxzUo+ixosXakvNHe 9t8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7wkEecOGBIx4MSTEg9IkfFASiIs9k/DtAoN1xO+4vUc=; b=TfQZDN0aMAJG27jte+Dzh4T1L9lOi7tODJYn2mZ9C6F9PVkJfV3pSfevx6iq9zOhsA itKQ3skaTw/55J8YyXEKFaf0BdK27NBtG4L0ZVkKnrMh4NtyRGm79iK1BtxNEscDpIrM NGz5jX51NoNZqRciq7dqZLkTDPc0LqQ5frrOnzfkxnwIOKK44spiuhu0tVJlvzvPz24K lYtcfP+Nh7KffbhSA3RB7VKytCNFhKG93ovsh2Pf5gdgeHeRUNWU60OYoLiTnCH1XEyT DrnbOzL2N73IPp/EBvDVs+gPTnmWn0Vk1AkpH7TJjtKPuZsRBQI/um3wJzo8eu4Fr7m8 fp0w== X-Gm-Message-State: AOAM533L/IyPKOXauwLt4CpcnDHF+fQjY9tNxsneE1MnpJjRV47zVeVj EOpJloUxvVZFzhieCsyUzjrQ7nN8GfZI4XdaoNU= X-Google-Smtp-Source: ABdhPJxBELWQeOtydOBuuaaAg4eKW7V/JsZsV8VgWQzoFpjf70ZRRcrBjqF96nYz7DL7XRfh45Ux6PBfrUwYgIzu39I= X-Received: by 2002:a02:b199:: with SMTP id t25mr61127jah.124.1601275968884; Sun, 27 Sep 2020 23:52:48 -0700 (PDT) MIME-Version: 1.0 References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> <01E82C2E-1F3E-49AD-B900-45B3F834A127@cisco.com> In-Reply-To: <01E82C2E-1F3E-49AD-B900-45B3F834A127@cisco.com> From: tirumal reddy Date: Mon, 28 Sep 2020 12:22:37 +0530 Message-ID: To: Eliot Lear Cc: Michael Richardson , opsawg , mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000050187605b05a1d30" Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 06:52:51 -0000 --00000000000050187605b05a1d30 Content-Type: text/plain; charset="UTF-8" On Sat, 26 Sep 2020 at 14:39, Eliot Lear wrote: > Hi Tiru > > On 26 Sep 2020, at 09:39, tirumal reddy wrote: > > In the home network use case, if the CPE does not support an encrypted DNS > forwarder, endpoint will discover and use the ISP encrypted DNS recursive > server. The CPE will no longer be able to enforce MUD rules. For instance, > Firefox can discover and use Comcast Encrypted DNS recursive server, see > https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html. > > > > Not necessarily. That is a matter of signaling between the CPE and the > ISP. > No, the special use domain name (SUDN) does not require any update to the CPE. The signaling from the endpoint is resolved by the ISP DNS recursive server and, it is not between the CPE and the ISP. -Tiru > > Eliot > --00000000000050187605b05a1d30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 26 Sep 2020 at 14:39, Eliot Lear = <lear@cisco.com> wrote:
Hi Tiru

On 26 Sep 2020, at 09:39, tirumal reddy <kondtir@gmail.com> w= rote:

In the = home network use case, if the CPE does not support an encrypted DNS forward= er, endpoint will discover and use the ISP encrypted DNS recursive server. = The CPE will no longer be able to enforce MUD rules. For instance, Firefox = can discover and use Comcast Encrypted DNS recursive server, see=C2=A0https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html= .=C2=A0


Not necessarily.=C2=A0 That is a matter= of signaling between the CPE and the ISP.
No, the special use domain name (SUDN) does not require any upd= ate to the CPE. The signaling from the endpoint is resolved by the ISP DNS = recursive server and, it is not between the CPE and the ISP.

=
-Tiru

Eliot
--00000000000050187605b05a1d30-- From nobody Mon Sep 28 00:03:58 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0883B3A096B; Mon, 28 Sep 2020 00:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 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 yxWKc4ongdCE; Mon, 28 Sep 2020 00:03:53 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B01E3A0928; Mon, 28 Sep 2020 00:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8807; q=dns/txt; s=iport; t=1601276633; x=1602486233; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=eRC7zWxffaKj3vNkuNogKm4Z28YPxdjrE5pokgS47Sw=; b=OgH2pSscWXJdSrVZM7C6+qHpI7VBjuyKWs5GrCHqgn2Edzh2c2v0boVj n9Cm2XVvlLqRcZMkPGQA+KLeAcwTX+xi02kHfqbcI/KK4axeIXzTJlqdD cyaQJmgvNNVW67JQKYTb8FauB74CbeyXIN3/uo7Sb1DJhk6mRuqtLgG6+ 4=; X-IPAS-Result: =?us-ascii?q?A0CvAAD9iXFf/xbLJq1fHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?gQBAQsBgSKBB4FFASASLIQ9iQKIHiaKDol6iBkLAQEBDQEBLwQBAYRLAoIxJ?= =?us-ascii?q?jcGDgIDAQEBAwIDAQEBAQUBAQECAQYEbYVohXIBAQEBAgEjBFIFCwsYKgICI?= =?us-ascii?q?TYGE4MmgkwDDiCzV3Z/M4VTglENgiSBOAGNSIIAgREnDBCCTT6CGoILgy8zg?= =?us-ascii?q?i0EkBOKSJwVUYJxgxOSO4UJAx+DDZ4GlQCLXI5cg10CBAYFAhWBaiQ3gSAzG?= =?us-ascii?q?ggbFWUBgj4+EhkNnGg/AzA3AgYBCQEBAwmPTQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,313,1596499200"; d="scan'208,217"; a="27518654" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Sep 2020 07:03:49 +0000 Received: from dhcp-10-61-108-189.cisco.com (dhcp-10-61-108-189.cisco.com [10.61.108.189]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 08S73m6O015869 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Sep 2020 07:03:48 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_83248D0C-F8D6-45ED-8706-A42A4A31A3DD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 28 Sep 2020 09:03:48 +0200 In-Reply-To: Cc: Michael Richardson , opsawg , mud@ietf.org To: tirumal reddy References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> <01E82C2E-1F3E-49AD-B900-45B3F834A127@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.108.189, dhcp-10-61-108-189.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 07:03:55 -0000 --Apple-Mail=_83248D0C-F8D6-45ED-8706-A42A4A31A3DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tiru > On 28 Sep 2020, at 08:52, tirumal reddy wrote: >=20 > Not necessarily. That is a matter of signaling between the CPE and = the ISP. >=20 > No, the special use domain name (SUDN) does not require any update to = the CPE. The signaling from the endpoint is resolved by the ISP DNS = recursive server and, it is not between the CPE and the ISP. All I am saying is this: ,--------. ,---. ,------. |Endpoint| |CPE| |ISPDNS| `---+----' `-+-' `--+---' | 1 A/AAAA Query | =20 | ---------------------------------> =20 | | | =20 | 2 Response(A/AAAA) | =20 | <--------------------------------- =20 | | | =20 | |3 add ACL/TR.369| =20 | | or similar | =20 | |<---------------- =20 ,---+----. ,-+-. ,--+---. |Endpoint| |CPE| |ISPDNS| `--------' `---' `------' You can substitute =E2=80=9CISPDNS=E2=80=9D for whoever offers the CPE = (like Google/Eero/etc, so long as the DNS infra and CPE know about one = another and agree on a control channel). Eliot --Apple-Mail=_83248D0C-F8D6-45ED-8706-A42A4A31A3DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tiru

On 28 Sep 2020, at 08:52, = tirumal reddy <kondtir@gmail.com> wrote:

Not necessarily.  That is a matter of signaling between = the CPE and the ISP.

No, the special use domain name (SUDN) = does not require any update to the CPE. The signaling from the endpoint = is resolved by the ISP DNS recursive server and, it is not between the = CPE and the ISP.

All I am saying is this:

     ,--------.        =   ,---.           = ,------.
     |Endpoint|        =   |CPE|           = |ISPDNS|
     `---+----'        =   `-+-'           = `--+---'
         |      =     1 A/AAAA Query          |   =  
         | = --------------------------------->    
         |       =           |          =       |    
         = |        2 Response(A/AAAA)      =   |    
         | = <---------------------------------    
         |       =           |          =       |    
         | =                 |3 add = ACL/TR.369|    
         | =                 | or similar =     |    
         | =                 = |<----------------    
     ,---+----.  =         ,-+-.           = ,--+---.
     |Endpoint|        =   |CPE|           = |ISPDNS|
     `--------'        =   `---'           = `------'

You can = substitute =E2=80=9CISPDNS=E2=80=9D for whoever offers the CPE (like = Google/Eero/etc, so long as the DNS infra and CPE know about one another = and agree on a control channel).

Eliot

= --Apple-Mail=_83248D0C-F8D6-45ED-8706-A42A4A31A3DD-- From nobody Mon Sep 28 00:07:35 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5862B3A0E60; Mon, 28 Sep 2020 00:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jG9o-mnlFrO0; Mon, 28 Sep 2020 00:07:32 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7D43A0928; Mon, 28 Sep 2020 00:07:32 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id u6so56293iow.9; Mon, 28 Sep 2020 00:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZLG6piFVHRJw8272BnfuSU58kuyfrYs0BIN36qHYDSo=; b=FMGxsaaSixJOXmzuSaLeemEJOO0zscNtSDHnCU7c2Ofjf6ZoK7hBth51Cj/jHmxIsN 96GHgH2KhUaln4eU677WJbiP5qyfocyyTVNvW0VP+ymbyZN9C6r5Pi+/aexoL0AhC79F D3WU+HXysvGSwOE+AmKpC1Rh+4KuzIYlEwfiIg+javp5I/hreZk6XYvyS70vCyBhqe6+ zopz7TlKxnOas/jV4PcrzXN9H6LVQeP5mIJ71+XYuVbghk1hK+VA2AGnZR/abw+BFSpt jY0r24Y7m7w7lZT0ctRbVwcZiMoMwSCuFpbYsdZCLkMQSNXAd0/luNDL9mntpkQY/pQ+ WAOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZLG6piFVHRJw8272BnfuSU58kuyfrYs0BIN36qHYDSo=; b=iKh4AEQDbtxgdmpWWfNUvl4FwRf9UZdW/ZO053BdFAsS+Rb9/gHoSDINiI4rW+z4VD 76Ye0XLb6wiN6tCuhRW6LpBKZtNDO44H9NntwtkxVqV1q9dsllPYF5hsn9dVOyoELFIk 4mxGFUMW2k9Off+VF3WXkzpaT+dWAOUMvCfQ9Xce9OsqWO7TYnaO7EpvndhOqbqKi6qN 4zvpWyKaF+m9Z+xXXxnlV/yWVqe7GwtLnwHXPIz5sgvRMi6x3m9hr40oPTjXX7Xzr1BH NgjPcliF39NDrYQEUabIoiEomb6dSId7C9dXK9258zWwpwv+cCqT9UhJAo5K0nX0rcDD T2SQ== X-Gm-Message-State: AOAM532yXn6kj7ZEuNGkEfV/use+0Y4Nh+zh6hchHTv+Psm/EIJni19V ID3wwFYn1pVsBcb8BtGA00Sa+q2vW2uvh2GFfgs= X-Google-Smtp-Source: ABdhPJwu+8u64FSVf+w6zZOuKezjt/5/4IB+An3Q0UDU1iR95NeuKvLEDOUWeLzRtyPYuJ4ORMLo3by1hl2IAUBUY74= X-Received: by 2002:a05:6638:309:: with SMTP id w9mr116231jap.58.1601276852023; Mon, 28 Sep 2020 00:07:32 -0700 (PDT) MIME-Version: 1.0 References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> <27239.1601161357@localhost> In-Reply-To: <27239.1601161357@localhost> From: tirumal reddy Date: Mon, 28 Sep 2020 12:37:20 +0530 Message-ID: To: Michael Richardson Cc: opsawg , mud@ietf.org, Eliot Lear Content-Type: multipart/alternative; boundary="000000000000f3b39505b05a5188" Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 07:07:34 -0000 --000000000000f3b39505b05a5188 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 27 Sep 2020 at 04:32, Michael Richardson wrote: > > tirumal reddy wrote: > >> tirumal reddy wrote: > >> > +1. The problem is not just with public resolvers but also with > >> > designated resolvers. The IoT device supporting MUD must use the > >> > encrypted DNS server discovered in the attached network. > >> > >> Yes-ish. > >> > >> I don't think that we have to mandate use of encrypted DNS servers= , > >> as long as it's the ones on the attached network. > >> > > > In the home network use case, if the CPE does not support an > encrypted DNS > > forwarder, endpoint will discover and use the ISP encrypted DNS > recursive > > server. The CPE will no longer be able to enforce MUD rules. For > instance, > > Firefox can discover and use Comcast Encrypted DNS recursive server= , > see > > https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html. > > It's reasonable that Firefox might do that, but I don't see why IoT devic= es > should follow suit, and that's the point of this document. > Except in some very niche digital signage and kiosk use, I don't think a > MUD > file would be appropriate for a general-purpose browser. > I quoted Firefox as an example, the proposed mechanism of using SUDN to discover the ISP encrypted DNS resolver is generic and not specific to browsers. If the endpoint cannot discover the local encrypted DNS server (hosted on the CPE) using DHCP/RA, the endpoint will fallback to using SUDN to discover the one hosted by the ISP. -Tiru > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > --000000000000f3b39505b05a5188 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, 27 Sep 2020 at 04:32, Michael Ric= hardson <mcr+ietf@sandelman.c= a> wrote:

tirumal reddy <ko= ndtir@gmail.com> wrote:
=C2=A0 =C2=A0 >> tirumal reddy <kondtir@gmail.com> wrote:
=C2=A0 =C2=A0 >> > +1.=C2=A0 The problem is not just with public r= esolvers but also with
=C2=A0 =C2=A0 >> > designated resolvers. The IoT device supporting= MUD must use the
=C2=A0 =C2=A0 >> > encrypted DNS server discovered in the attached= network.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Yes-ish.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I don't think that we have to mandate use of enc= rypted DNS servers,
=C2=A0 =C2=A0 >> as long as it's the ones on the attached network= .
=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 > In the home network use case, if the CPE does not suppor= t an encrypted DNS
=C2=A0 =C2=A0 > forwarder, endpoint will discover and use the ISP encryp= ted DNS recursive
=C2=A0 =C2=A0 > server. The CPE will no longer be able to enforce MUD ru= les. For instance,
=C2=A0 =C2=A0 > Firefox can discover and use Comcast Encrypted DNS recur= sive server, see
=C2=A0 =C2=A0 > https://tools.ietf.org= /id/draft-rescorla-doh-cdisco-00.html.

It's reasonable that Firefox might do that, but I don't see why IoT= devices
should follow suit, and that's the point of this document.=C2=A0

Except in some very niche digital signage and kiosk use, I don't think = a MUD
file would be appropriate for a general-purpose browser.

I quoted Firefox as an example, the proposed mechanism of= using SUDN to discover the ISP encrypted DNS resolver is generic and not s= pecific to browsers. If the endpoint cannot discover the local encrypted DN= S server (hosted on the CPE) using DHCP/RA, the endpoint will fallback to u= sing SUDN to discover the one hosted by the ISP.

-= Tiru
=C2=A0
mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




--000000000000f3b39505b05a5188-- From nobody Mon Sep 28 00:14:23 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492F93A0400; Mon, 28 Sep 2020 00:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpQvzzJAWlK0; Mon, 28 Sep 2020 00:14:16 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 9B73A3A03FC; Mon, 28 Sep 2020 00:14:16 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id u6so72790iow.9; Mon, 28 Sep 2020 00:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+8nGvjjazHkm3lOM1VVmhXQ7juz4d2mq5DsKurfqiIg=; b=IegI0FhY86K8GUcATySJcjQVJnI5zj0z2udb216wh1ffA7tPJtALyLNRYHAY9lNcqz eLN7juGSt4WomCMppTSeIp6F/zMGlYZG7aySLE8mQeVb9RqJnYbBWZVtFXgbmkXGzDts luVvRE4HEeMBp91VG4zrb4mAgPfOfw/uNNOKJ3SKbGaFfAliLxoWAd3kSIF75HiYGRt/ yHGVotJbCexmJewfpywHlYUJlr3picYAs2G59IzYu0LdzGRnwdoyMj9TYI1TREO/LcUF CGQlnQG0nIVFZumxc10BehQ+yuPtop0yEdGecLx19XzMtJGWb8/uCormS7SrZvvC4mbW gNLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+8nGvjjazHkm3lOM1VVmhXQ7juz4d2mq5DsKurfqiIg=; b=e843fXEP1RoCU/2+q4aRT+9qBRQi1H3c1wcao06F/Yi37xzo3vu8ZmghHqjW4HsEQa fdflf1oTr+cVb3kBrv+e1orjS7fYgNBsy5ou8lUUJe11f0lnLaZ6hzi80Ms/WYWmXWu/ 1aZumnN3J6IPf0ACD2zYtVqtuAGLnyumdwsd+sJ5KJ2RdZfV7ATF2x+rdmwHjADtI2xW FL4Wm9x6mwvFg3PT3+oRh7v6iE43q1rJFDhRvKiEGp10OuMVtpOO5tMy9Cc7No3wSiGt xS7BEZjopjg6ReBT7K/lulWrghaA9TIxxcRc0DES+jLbLlJTaXxZIeN9aDHlmOwGKHfm B/2Q== X-Gm-Message-State: AOAM5325jwjlfdsKdIDdrkYWUujBsG9U6QpjLavqclID/AHrBQjAx9Or xHZuQLrEA+q6qz5W+lDE4Der1O8PyN8xLXXLXKkaCz99vwYOBA== X-Google-Smtp-Source: ABdhPJyC/wnn36OiflRXHaCwJyYYBsETktgdVCXtX7AK7kIa9Qzh/HH4YDnmMmMm4+O/d0t/JMarHWX+qhC1inr1gMk= X-Received: by 2002:a05:6602:14c3:: with SMTP id b3mr1885710iow.164.1601277255932; Mon, 28 Sep 2020 00:14:15 -0700 (PDT) MIME-Version: 1.0 References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> <01E82C2E-1F3E-49AD-B900-45B3F834A127@cisco.com> In-Reply-To: From: tirumal reddy Date: Mon, 28 Sep 2020 12:44:04 +0530 Message-ID: To: Eliot Lear Cc: Michael Richardson , opsawg , mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000006e09105b05a6ae2" Archived-At: Subject: Re: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 07:14:18 -0000 --00000000000006e09105b05a6ae2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 28 Sep 2020 at 12:33, Eliot Lear wrote: > Tiru > > On 28 Sep 2020, at 08:52, tirumal reddy wrote: > >> >> Not necessarily. That is a matter of signaling between the CPE and the >> ISP. >> > > No, the special use domain name (SUDN) does not require any update to the > CPE. The signaling from the endpoint is resolved by the ISP DNS recursive > server and, it is not between the CPE and the ISP. > > > All I am saying is this: > > ,--------. ,---. ,------. > |Endpoint| |CPE| |ISPDNS| > `---+----' `-+-' `--+---' > | 1 A/AAAA Query | > | ---------------------------------> > | | | > | 2 Response(A/AAAA) | > | <--------------------------------- > | | | > | |3 add ACL/TR.369| > | | or similar | > | |<---------------- > ,---+----. ,-+-. ,--+---. > |Endpoint| |CPE| |ISPDNS| > `--------' `---' `------' > > You can substitute =E2=80=9CISPDNS=E2=80=9D for whoever offers the CPE (l= ike > Google/Eero/etc, so long as the DNS infra and CPE know about one another > and agree on a control channel). > Yes, that should work for managed CPE. ISPs and security vendors want to host a encrypted DNS forwarder on the home router itself, see https://tools.ietf.org/html/draft-box-add-requirements-00#section-3.1.2 and https://tools.ietf.org/html/draft-campling-operator-observations-00 -Tiru > > Eliot > > --00000000000006e09105b05a6ae2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 28 Sep 2020 at 12:33, Eliot Lear = <lear@cisco.com> wrote:
Tiru

On 28 Sep 2020, at 08:52, tirumal reddy <kondtir@gmail.com> wrote:=

Not necessarily.=C2= =A0 That is a matter of signaling between the CPE and the ISP.
<= /blockquote>

No, the special use domain name (SUDN) does= not require any update to the CPE. The signaling from the endpoint is reso= lved by the ISP DNS recursive server and, it is not between the CPE and the= ISP.

All I am saying is= this:

=C2=A0 =C2=A0 =C2=A0,--------.=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 ,---. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ,----= --.
=C2=A0=C2=A0 =C2=A0 |Endpoint|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |CPE| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |ISPDNS|
=C2=A0=C2=A0 =C2=A0 `---+----'=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 `-+-' =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 `--+---'
<= div style=3D"margin:0px;font-stretch:normal;font-size:14px;line-height:norm= al;font-family:Menlo">=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 1 A/AAAA Query=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 | -----------------------------= ----> =C2=A0 =C2=A0
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 2 Response= (A/AAAA)=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0
=C2= =A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 | <--------------------------------- =C2= =A0 =C2=A0
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |3 add ACL/TR.369| =C2=A0 =C2=A0
=C2=A0=C2=A0= =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | or similar =C2=A0 =C2=A0 | =C2=A0 =C2=A0
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |<---------------- =C2=A0 =C2=A0
=C2=A0=C2= =A0 =C2=A0 ,---+----.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ,-+-. =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 ,--+---.
=C2=A0=C2=A0 =C2=A0 |Endp= oint|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |CPE| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |ISPDNS|
=C2=A0=C2=A0 =C2=A0 `--------'=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 `---' =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 `= ------'

You can substitute =E2=80=9CISPDNS=E2=80=9D for whoever = offers the CPE (like Google/Eero/etc, so long as the DNS infra and CPE know= about one another and agree on a control channel).

Yes, that should work for managed CPE. IS= Ps and security vendors want to host a encrypted DNS forwarder on the home = router itself, see=C2=A0https://tools.ietf.org/html/draft-box-add-= requirements-00#section-3.1.2 and=C2=A0https://tools.ietf.org/html= /draft-campling-operator-observations-00=C2=A0

-Tiru
=C2=A0

Eliot

=
--00000000000006e09105b05a6ae2-- From nobody Mon Sep 28 11:39:24 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582913A1353; Mon, 28 Sep 2020 11:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weKSvcYoBJhW; Mon, 28 Sep 2020 11:39:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA553A1351; Mon, 28 Sep 2020 11:39:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D364E389B3; Mon, 28 Sep 2020 14:44:09 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t9mpeEPRQZV3; Mon, 28 Sep 2020 14:44:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BC11D389B1; Mon, 28 Sep 2020 14:44:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C92F6570; Mon, 28 Sep 2020 14:39:15 -0400 (EDT) From: Michael Richardson To: tirumal reddy cc: opsawg , mud@ietf.org, Eliot Lear , paul vixie In-Reply-To: References: <160082461431.2339.6222888407127336620@ietfa.amsl.com> <15779.1600960819@localhost> <15491.1601055706@localhost> <27239.1601161357@localhost> 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: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 18:39:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tirumal reddy wrote: >> Except in some very niche digital signage and kiosk use, I don't thi= nk >> a MUD file would be appropriate for a general-purpose browser. >> > I quoted Firefox as an example, the proposed mechanism of using SUDN = to > discover the ISP encrypted DNS resolver is generic and not specific to > browsers. > If the endpoint cannot discover the local encrypted DNS > server (hosted on the CPE) using DHCP/RA, the endpoint will fallback = to > using SUDN to discover the one hosted by the ISP. Yeah, but, we really don't want this. Way better, in my opinion, for privacy,security (MUD), and device ownership if the IoT device sticks with Do53 on the LAN, rather than encrypted DNS to= the ISP. =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+93Q3WUFAl9yLdMACgkQgItw+93Q 3WUAmQf+NAPL+bewcm/usrTKDAuYXb0SrITFzt6tjTmmKWH86Qi9Pho8MFy0CslO FoY5t80dUW6HSYtC/Eqx7HdNb0I49jNw0gcIUeBSoB6Sn/hAjP0mGMq5ymcto5BL Q6jD4Jz9uKY6+sIIu0VAqLVxmOpngJWP8ockVrif2pHdoWAwJGBOzSpg39pxhNdd /dqTA2k0i6Lvp+Z0eNnz8iV5NwjfODj0nTSIUnkVjMHXtx5hitvOuyPzm861ERA1 G2EJsIkqxIQAemhls5BczDvUf/K0/KAygN8uuvZkBq4dvKVP/eWLzmTYmNEbMbjz fX/vb5al3OYvGBdGGR92/7EaeD/lbQ== =TqiW -----END PGP SIGNATURE----- --=-=-=--