From nobody Mon Jun 3 01:42:14 2019 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 0977312012C for ; Mon, 3 Jun 2019 01:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 tec7cE2QyyJb for ; Mon, 3 Jun 2019 01:42:11 -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 97B06120046 for ; Mon, 3 Jun 2019 01:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2914; q=dns/txt; s=iport; t=1559551330; x=1560760930; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=AtKIuKxACWJba0Hl3OP3MqV3K2VxN1KxI64Ilz2E9EI=; b=VxWtEjFgI2cT6uTuguzII5NtFZHsmy8tL9jtSzFUT2yh3ywcf2uJFL1W YRi3F7vHidaT0FVV0Jn4gBb7RWv4uXHEVkr7qrtWigauGOiyuupyML6dz tL00uzbET8KQD4c/WnWkxonayAlz2Msgnf36CUzf6P61KatI3u+JmES+f 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiAABp3PRc/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYNINyiEFIh7i3MlmHGBZwIHAQEBCQMBAS8BAYFLgnUCgzA?= =?us-ascii?q?4EwEDAQEEAQECAQRtKIVKAQEBAQIBI0wKBQsLGCoCAlcGE4MiAYF7D6kFgTG?= =?us-ascii?q?FR4RTEIE0gVCKIYF/gTgME4IeLj6EEQESAYMpMoIEIgSLMIhClQcJgg+CGIE?= =?us-ascii?q?GjWOCMRuMbooAoBqDBAIEBgUCFYFmIWdxMxoIGxVlAYJBPoFdF44iPQMwjwE?= =?us-ascii?q?PFwSCKAEB?= X-IronPort-AV: E=Sophos;i="5.60,546,1549929600"; d="asc'?scan'208";a="12685169" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jun 2019 08:42:08 +0000 Received: from [10.61.228.92] ([10.61.228.92]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x538g7RC024294 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Jun 2019 08:42:08 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_423575AE-579E-41D3-ACE6-BE036DF198F7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 3 Jun 2019 10:42:05 +0200 In-Reply-To: <5960.1558214710@localhost> Cc: mud@ietf.org To: Michael Richardson References: <17454.1557618668@localhost> <5960.1558214710@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.228.92, [10.61.228.92] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Mud] what if MUD file is now longer available? 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, 03 Jun 2019 08:42:13 -0000 --Apple-Mail=_423575AE-579E-41D3-ACE6-BE036DF198F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 May 2019, at 23:25, Michael Richardson = wrote: >=20 >=20 > Eliot Lear wrote: >>> Section 13.2 says that the MUD-manager should cease processing at = that point. >>> I guess at that point, the access should therefore be default-deny. >>> I guess the other question is what would the access be if there were = no >>> MUD URL at all. We'd all like to be default-deny, but I think that = during >>> a transition period it can't be that. >=20 >=20 >> If you ever had a valid MUD file you should keep using it. This >> follows the principle of least astonishment. Otherwise, a temporary >> outage might cause policy flaps. An alternative might be to invoke = an >> exception flow that says, =E2=80=9Cyo! No more MUD file=E2=80=9D. >=20 > Yes, I'm asking: what if the MUD-manager never got a valid MUD file. > It did exist at some point, but then marketing moved it when they = redid the > web site, or the company just went under. I think this ties to the draft we discussed putting together in Prague. = That is- a search path of sorts. >=20 >> A few things to think about with this use case. We really don=E2=80=99= t have >> contact information in the MUD file. While one might think that an >> oversight, honestly I get a little nervous about sticking email >> addresses in various places that can be harvested for SPAM. >=20 > The contact info does not have to be an email address. >=20 > It could point to quite a number of other things. > There are some identities out there like 1id.com, Dun&Bradstreet = numbers, RIR > handles, URLs, =E2=80=A6 >=20 True- in YANG terms this would be a CHOICE. Let=E2=80=99s not go crazy = with the # of choices, tho. Eliot > ... >=20 > Consider the opposite consideration: without a contact, one has no = ability to > find out who is liable. That would be a relatively low-bar for an = import > regulation. Every device gets a verifiable contact, or it does not = get past > customs. The QR code on the case containing the MUD URL provides = that. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 --Apple-Mail=_423575AE-579E-41D3-ACE6-BE036DF198F7 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXPTdXgAKCRBugA9nE248 uGabAJ9vK6E2BPYoP+ENuPK5exHOt6kFRACfR29YLa1RJLpEeh6gwRZXOPNd+DI= =POQ8 -----END PGP SIGNATURE----- --Apple-Mail=_423575AE-579E-41D3-ACE6-BE036DF198F7-- From nobody Mon Jun 3 11:27:06 2019 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 211C1120120 for ; Mon, 3 Jun 2019 11:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 uA_9Qm12F9LC for ; Mon, 3 Jun 2019 11:27:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62F4120161 for ; Mon, 3 Jun 2019 11:27:02 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E58793808A; Mon, 3 Jun 2019 14:25:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1925F16A5; Mon, 3 Jun 2019 14:27:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 16B30E69; Mon, 3 Jun 2019 14:27:01 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: mud@ietf.org In-Reply-To: References: <17454.1557618668@localhost> <5960.1558214710@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] what if MUD file is now longer available? 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, 03 Jun 2019 18:27:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >> Eliot Lear wrote: >>>> Section 13.2 says that the MUD-manager should cease processing at = that point. >>>> I guess at that point, the access should therefore be default-deny. >>>> I guess the other question is what would the access be if there we= re no >>>> MUD URL at all. We'd all like to be default-deny, but I think tha= t during >>>> a transition period it can't be that. >> >> >>> If you ever had a valid MUD file you should keep using it. This >>> follows the principle of least astonishment. Otherwise, a temporary >>> outage might cause policy flaps. An alternative might be to invoke= an >>> exception flow that says, =E2=80=9Cyo! No more MUD file=E2=80=9D. >> >> Yes, I'm asking: what if the MUD-manager never got a valid MUD file. >> It did exist at some point, but then marketing moved it when they re= did the >> web site, or the company just went under. > I think this ties to the draft we discussed putting together in Pragu= e. > That is- a search path of sorts. Yes. We agreed that it was more than a local decision because there is the issue of how the signatures will work. Both where the signature is to be found, and how the MUD file can be amended with new signatures. (I know very little about WebDAV's PATCH method. I see that in rfc4918 the= re is PROPPATCH, and it seems to apply to XML content. I was thinking that maybe we could borrow from that specifications to describe modifications, a= nd sign those) >>> A few things to think about with this use case. We really don=E2= =80=99t have >>> contact information in the MUD file. While one might think that an >>> oversight, honestly I get a little nervous about sticking email >>> addresses in various places that can be harvested for SPAM. >> >> The contact info does not have to be an email address. >> >> It could point to quite a number of other things. >> There are some identities out there like 1id.com, Dun&Bradstreet num= bers, RIR >> handles, URLs, =E2=80=A6 >> > True- in YANG terms this would be a CHOICE. Let=E2=80=99s not go cra= zy with the # of choices, tho. Fair enough. Isn't URI probably enough? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz1ZnQACgkQgItw+93Q 3WUhywgAg1WDNp1GtGkw6phN2USYBqMxgrlC6NljEk7YtQVE1F+G8BTddKRtsUsH DzTL1dCMrWVv1nHC9O6NJ0J3DOXnWslEUBjB5TED+/+nYSaWEdk4oMvfUnHjsC02 0s+ZeSlvCdReuEvXUpJwORYsHqTFrVQD25fOFjMqj4Nm+h+OK+T9hg9r0vlWG/Z5 cvY9HEsYXgex6dAAumDIhLYxGl1UtbXWHj4m3//F0rA1RUb03b9NttdNGzx5tvPN B+Atvlt6+OREDhQxiYEah2q2jJUauCgptRCjs+kSdNjEdKdHmDnUHSwSaGDiI6hc Wz1YMI2/ffxGZ+YS25eoCquLcVQGyQ== =91ul -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 5 06:33:39 2019 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 B061812006E for ; Wed, 5 Jun 2019 06:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidnka.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP2gwiPlo_8P for ; Wed, 5 Jun 2019 06:33:35 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80041.outbound.protection.outlook.com [40.107.8.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E749120045 for ; Wed, 5 Jun 2019 06:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SIDNKA.onmicrosoft.com; s=selector1-SIDNKA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sKZUIbJCp5MCAtTxv5AE2WFaYbPyDeemYy5xvEs7oYY=; b=ePsX7O1PNqfAxCGGN9eyMGSV+ZimPzSQDPD7tmBCb4ZJ5VMx0DbCNSTLUN65HottWMZt1a+VZ7+yTjL+1eA/SxsVXk84KjErB0Ub5RmRiYOXq6Zwoac0oxMX1uAgXlSYJdBgb/CAM/tCHd5vSVnkjFZdsXjLwNWlatLolTp/MHU= Received: from AM0P194MB0323.EURP194.PROD.OUTLOOK.COM (52.134.124.25) by AM0SPR01MB0045.EURP194.PROD.OUTLOOK.COM (20.179.32.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Wed, 5 Jun 2019 13:33:32 +0000 Received: from AM0P194MB0323.EURP194.PROD.OUTLOOK.COM ([fe80::a4c8:a0df:d735:494a]) by AM0P194MB0323.EURP194.PROD.OUTLOOK.COM ([fe80::a4c8:a0df:d735:494a%5]) with mapi id 15.20.1965.011; Wed, 5 Jun 2019 13:33:32 +0000 From: Ad Bresser To: "mud@ietf.org" Thread-Topic: [Mud] Unique credentials for devices in a home network Thread-Index: AQHVFCuD9lUWrhZCe0Wvbu6iapAGmqZ+gQ0AgAA7JgCAAHk6gIAA2JgAgAEXEYCAC/gYkA== Date: Wed, 5 Jun 2019 13:33:32 +0000 Message-ID: References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <32236.1558976943@localhost> <19145.1559083385@localhost> In-Reply-To: <19145.1559083385@localhost> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ad.Bresser@sidn.nl; x-originating-ip: [2a00:d78:0:300:d12d:cdf:9c6f:6d0e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e9049a2-6a9b-4e3f-648b-08d6e9ba6770 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM0SPR01MB0045; x-ms-traffictypediagnostic: AM0SPR01MB0045: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(39840400004)(346002)(136003)(189003)(199004)(68736007)(4744005)(6436002)(6506007)(81156014)(305945005)(6246003)(25786009)(76116006)(446003)(66946007)(6306002)(86362001)(486006)(71190400001)(71200400001)(8676002)(14454004)(7696005)(256004)(2351001)(229853002)(74316002)(99286004)(186003)(55016002)(81166006)(66556008)(66446008)(64756008)(2906002)(8936002)(66476007)(5640700003)(14444005)(5660300002)(1730700003)(74482002)(316002)(476003)(73956011)(72206003)(7736002)(2501003)(9686003)(66574012)(76176011)(508600001)(52536014)(46003)(53936002)(6116002)(6916009)(11346002)(33656002)(102836004)(966005)(222643001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0SPR01MB0045; H:AM0P194MB0323.EURP194.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: sidn.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pjYqxAM0fs5exnosba9lgcXuuR0SpN8+QbL5ukVWZD93Xlsp3nYCGdVqaQowNdswQjBIoyObNK9gBHNbtcpKmElYv19OvRz5PEgHfOZo1nWo4zAny2U0OJwH/hLLXoVjuAKVQc2tlabB8MfnzGAvQIvpuUqei0WmaZRwM9ylKpah/I40nIVDdpdXMsgtb2HeMnf//MY3xI4G4rVFBbP4K7y0YIEfVqM4+hAbtPYG1c1utxtBHKs2ze+JWi46nlmOYTNJyWQJORki6JuHdsi2Mn/P0ekZAbMnOl0GAbrD88h+xzmjSZ+Vp3+QnMb/1l5cV2hIdrPT90mtVM6qmnkeSZg7g4FUZCf9S2sJOczHnDYf1rKWabd+lLys1L0UCH18R15y8ut5+LkKs8evC1im3iI8B+3+YMY410Tpl29gVAE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 5e9049a2-6a9b-4e3f-648b-08d6e9ba6770 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 13:33:32.6582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ad.Bresser@SIDN.nl X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0SPR01MB0045 Archived-At: Subject: Re: [Mud] Unique credentials for devices in a home network 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, 05 Jun 2019 13:33:38 -0000 SGksDQoNCj4gU3ViamVjdDogUmU6IFtNdWRdIFVuaXF1ZSBjcmVkZW50aWFscyBmb3IgZGV2aWNl cyBpbiBhIGhvbWUgbmV0d29yaw0KPiANCj4gICAgbWNyPiBEbyB3ZSBuZWVkIHRvIHdyaXRlIGFu IE9wZXJhdGlvbmFsIEJDUCBmb3IgSW9UIGFuZCBETlMgaGVyZT8NCj4NCj4gdGlydW1hbCByZWRk eSA8a29uZHRpckBnbWFpbC5jb20+IHdyb3RlOg0KPiAgICA+IFllcywgbG9va3MgdXNlZnVsIHRv IG1lLg0KPg0KPiBjb3VsZCB0aGVyZSBiZSBzb21lb25lIGVsc2Ugd2hvIHdhbnRzIHRvIHdyaXRl IHRoaXM/DQoNClRvIHNhdmUgc29tZSB3cml0aW5nIHRpbWU6IA0KVGhlIElDQU5OIFNTQUMgKFNl Y3VyaXR5IGFuZCBTdGFiaWxpdHkgQWR2aXNvcnkgQ29tbWl0dGVlKSwgcHVibGlzaGVkOg0KU0FD MTA1IFRoZSBETlMgYW5kIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3M6IE9wcG9ydHVuaXRpZXMsIFJp c2tzLCBhbmQgQ2hhbGxlbmdlcw0KaHR0cHM6Ly93d3cuaWNhbm4ub3JnL2VuL3N5c3RlbS9maWxl cy9maWxlcy9zYWMtMTA1LWVuLnBkZiAgIA0KDQpLaW5kIHJlZ2FyZHMsIA0KDQpBZCBCcmVzc2Vy DQoNCg== From nobody Wed Jun 5 09:26:14 2019 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 4D57312018C for ; Wed, 5 Jun 2019 09:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 dpxUPoVCvTW1 for ; Wed, 5 Jun 2019 09:26:04 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 90B2F1201D5 for ; Wed, 5 Jun 2019 09:26:04 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id j204so4458098ite.4 for ; Wed, 05 Jun 2019 09:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ixojY3u7IeqKyHEIzc4QrPjY78D8u98IF0H5HT3dO9A=; b=Ga7ZG2eEI+YBqumG9iuaBvy98HsA798kMsMe2lQaHD+gWBAaf7aia0q2OG6hPtG3L8 HTqbfPVkirhTSiad88+hGTMhjYBO45xiZHEHnBh368Upiu5uodoLVmh1b18eH4TEkmSV S9DZ4BsEAc8B7sLMPXC/DK8GNu06YrEQCNo6hW6Lzio60X8wAEZQjx/+P7nC9iV2wyro AHNSqhPsocI9FD+P9ZBZDhRSRdTezSfxW48ekEobKqc1sytBD/gHiGo+sXIhnQMzyCg4 DGeuFxacMdvCDqVrRpsKTn3AIxD0JdCTvMiLdLqf40jodTaxfj01BWiv2xqT9JT6hDa5 9DkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ixojY3u7IeqKyHEIzc4QrPjY78D8u98IF0H5HT3dO9A=; b=abzbVjehH9I9Nq0+9AC3a4EZF5619JOpCBW36smXMjRxq5zW2It/6r1fJ4Z6g5QcZZ pxkaA4FdeaXbbyn5a6lTGGHVw+OdROuvE0Z0DcNXBkohco0lHZg5dsme9Ko+0hCw3moM kQEqI6G6t51F5l70wFuezV0cchcwMeEPrYFJYSzDe2yOFiltRFXL+T5K3mPi7SwE0EZH HYmzpSU1MiyzKsm+dAYzhMZIjyOZaRYnoCXvl4r3QaPTyX5MDfYZNmxZY94dFXDyzqmI 4Ve+Djfu3u1u/W1/T1ZYYqE4iYo3izT2l0kHXnUkgZvvLzRgLT3Cj0YeKd0gp1y9kSfe yrtw== X-Gm-Message-State: APjAAAUp0XKrur7Qki6flXDaSEWPXSsRL1m0O4dqmCe67n70N2QFluCY nY7uGYYdORNY9O5BQLwMvmux+AWqm2dd892awySnUQ== X-Google-Smtp-Source: APXvYqyjq3Z9PGNBlwx1W5M8OxsZO6IktNaJI5MthIOLDZ0aZzcdZXZ+cYxg11PQld5/RyTGb/y6P1PTXYNFRDpyYDY= X-Received: by 2002:a24:4344:: with SMTP id s65mr13414020itb.137.1559751963409; Wed, 05 Jun 2019 09:26:03 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Wed, 5 Jun 2019 12:25:27 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000b781f6058a960dd3" Archived-At: Subject: [Mud] Hackathon topics for IETF 105 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, 05 Jun 2019 16:26:13 -0000 --000000000000b781f6058a960dd3 Content-Type: text/plain; charset="UTF-8" There is going to be a "hackathon table" for IETF 105. Here are some ideas that occurred to me: - Quarantine : Mechanisms to isolate devices that violate MUD-specified ACEs. - Logging and Event notifications : If a MUD-enable device violates its allowed behavior, one approach is to summarize the violations and send event notifications to some centralized event-gathering point. What to report and to whom? Should we incorporate rate specifications so excessive connections or packet rates can be logged and notified. Any other candidates? -- M. Ranganathan --000000000000b781f6058a960dd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is going to be a "hackathon table" fo= r IETF 105. Here are some ideas that occurred to me:

- Quarantine : Mechanisms to isolate devices that violate MUD-specified = ACEs.
- Logging and Event notifications : If a MUD-enable device = violates its allowed behavior, one approach is to summarize the violations = and send event notifications to some centralized event-gathering point. Wha= t to report and to whom? Should we incorporate rate specifications so exces= sive connections or packet rates can be logged and notified.

=
Any other candidates?



--
M. Ranganathan

=
--000000000000b781f6058a960dd3-- From nobody Wed Jun 5 09:54:31 2019 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 656DC120198 for ; Wed, 5 Jun 2019 09:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 ULCwClfPeEWu for ; Wed, 5 Jun 2019 09:54:28 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5646712018E for ; Wed, 5 Jun 2019 09:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2168; q=dns/txt; s=iport; t=1559753668; x=1560963268; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=uYiCU2jJe2KeQ+LrWFO5EuuZNDj8IPtBdE2rczIKilk=; b=Y69sjuSgiHk7v6uC4VTji4BwukFrlkmFgg/nYF6gj2R7mlTUQA4XXzny nZ7TmmkEFCiEZpHs/KeS22n9HP8aUN9knjrEjfU0pClZemmjwAuwm4lSa mAss7jLFf+1/bDl3t+2uo6aiyNGu8z9F2k0TXDdI0f/oKmKjoRpPUGpgF 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAQ8/dc/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgWaBFFEhEiiEFIh7i14liUKPHBSBZwI?= =?us-ascii?q?HAQEBCQMBARgLDAEBhEACgnk2Bw4BAwEBBAEBAgEEbRwMhUoBAQEDAQEBIUs?= =?us-ascii?q?LBQsLGCoCAiEGMAYTgldLAYFqAw4PD6ZcgTGFR4I6DYITCgaBNAGBT4oigX+?= =?us-ascii?q?BOAwTgh4uPoEEgRZHAQGBLgESAYMpMoImBJN+lFQ+CYIQghqBBowwg2objHW?= =?us-ascii?q?KCpYBijeDBgIEBgUCFYFVATFncTMaCBsVOyoBgkE+gWmIbIVBPQMwjUANFwe?= =?us-ascii?q?CJQEB?= X-IronPort-AV: E=Sophos;i="5.60,550,1549929600"; d="asc'?scan'208";a="12831402" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jun 2019 16:54:26 +0000 Received: from [10.61.210.184] ([10.61.210.184]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x55GsOlt027126 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Jun 2019 16:54:26 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_35B8372C-581B-49B5-8F30-1B86F24AAA23"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 5 Jun 2019 18:54:24 +0200 In-Reply-To: Cc: mud@ietf.org To: "M. Ranganathan" References: X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.210.184, [10.61.210.184] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Mud] Hackathon topics for IETF 105 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, 05 Jun 2019 16:54:30 -0000 --Apple-Mail=_35B8372C-581B-49B5-8F30-1B86F24AAA23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ranga, Validating and cleaning up Mudmaker. For these below. > On 5 Jun 2019, at 18:25, M. Ranganathan wrote: >=20 > There is going to be a "hackathon table" for IETF 105. Here are some = ideas that occurred to me: >=20 > - Quarantine : Mechanisms to isolate devices that violate = MUD-specified ACEs. For hacking=E2=80=A6 we need to have a good feel for the starting point = in terms of how to code. This looks like it=E2=80=99s tied to = logging... > - Logging and Event notifications : If a MUD-enable device violates = its allowed behavior, one approach is to summarize the violations and = send event notifications to some centralized event-gathering point. What = to report and to whom? Should we incorporate rate specifications so = excessive connections or packet rates can be logged and notified. Right. What=E2=80=99s the reporting mechanism? I=E2=80=99m working on = a draft for this now, which I will be happy to share in a week or two. = We will need a MUD extension for this (the reporting address). Michael = and I were going back and forth about this. I do not want to simply = say, =E2=80=9CURI=E2=80=9D because there are too many schemes out there. = We know that email has to be one approach. Do we want RESTful = interfaces as well for these reports? >=20 > Any other candidates? >=20 >=20 >=20 > -- > M. Ranganathan >=20 > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud --Apple-Mail=_35B8372C-581B-49B5-8F30-1B86F24AAA23 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXPfzwAAKCRBugA9nE248 uFXqAJ9J6OfMZe9NbZXMgpzobghZ4x01tQCgrkAwhdo2MXHlG4ozQ9K0XzSWahQ= =bWnS -----END PGP SIGNATURE----- --Apple-Mail=_35B8372C-581B-49B5-8F30-1B86F24AAA23-- From nobody Wed Jun 5 20:44:11 2019 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 1DB0A1200E5 for ; Wed, 5 Jun 2019 20:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 SRgbOo0yFxg4 for ; Wed, 5 Jun 2019 20:44:07 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 9BD9A12008F for ; Wed, 5 Jun 2019 20:44:07 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id k13so719460iop.5 for ; Wed, 05 Jun 2019 20:44:07 -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=uK/fTMPxgqoj1QLmtwlJPlIm6mOwVcH2j4oVS0A75wI=; b=cFo6gU7cUdREwYAEA2zMVk0fc/nsQJhb5CgjFvgCcdYfepVjC/bLSZiEbvEiIBSKz9 AY47VWZpL8xu/1HyRNBs+z3wennrfZqc0FCf1bFvsDB12CkFk+N/sf5ReVIhRVxOI3sd 264yQ1MS8q91xwfAR9B64uBR9OLtQEjV6tqKmB1TbAJFOVs8OS8ySBkr5AcTUx8kWfL3 rXfz77aTjzgbuXcfAUl/0CWm8Od7I31Hl103geyIYuuTeTdfQ7UdZPDUEvChgUudhVvh zUbLo1GKRnIBGRFzRs05OnP8yZ63ym5WLYWeTDAn5eyyNc2BAQQhpSS/W4+3QOTjqgKU 0RGQ== 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=uK/fTMPxgqoj1QLmtwlJPlIm6mOwVcH2j4oVS0A75wI=; b=nNSD5FppA0JTLj/PTtJex9CVM/O3rHrsaCev2howpEodDJmYAyFfqN6xq9yNtkESLZ eleA9JKSuHUReOCGjlfTM4sdn7cjSk8DJs1Fm7u5VZ3a6fWsL7mhTe0C2Ly9HjXmPFAK IRWBdoYGIydj8SUxQS9LC1VFFodFEIjQkgpKmk6WOcgJoqwz7e3zmkEwsPga3Pax82Hz DjUKXzqIeCxxgaPYhKubKFEkJVW6DNiHqD8Vwi1gZv1Fbh4yXLiqkDiIrsUhVowOQvG+ 0Pqdhk7a/QF0BQ1W2tMSyaMYKAZCgQsOkzvTZZgaFGf45GVI4Qq1Pz2VnGxjOGaZ38tR aYoA== X-Gm-Message-State: APjAAAVnBG+qpOAAxycuZoNbVLTowxKUgrwbkgwkbgtqPa1rq+u31RdR J0SQSfOzyUypGFETbagvUsTYd9bhWXFjrQMW1hw= X-Google-Smtp-Source: APXvYqwtb0+4vp3ZTV5XQE68WuJScWlCt6WDsWGTnpupqCLasfrViNvUjyUnoEylpx2r+qTz+tAsWJaPQTpekLV4CCc= X-Received: by 2002:a5d:9448:: with SMTP id x8mr24095756ior.102.1559792646464; Wed, 05 Jun 2019 20:44:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "M. Ranganathan" Date: Wed, 5 Jun 2019 23:43:29 -0400 Message-ID: To: Eliot Lear Cc: mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000009da82e058a9f865c" Archived-At: Subject: Re: [Mud] Hackathon topics for IETF 105 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, 06 Jun 2019 03:44:10 -0000 --0000000000009da82e058a9f865c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Eliot, On Wed, Jun 5, 2019 at 12:54 PM Eliot Lear wrote: > Hi Ranga, > > Validating and cleaning up Mudmaker. For these below. > I'd say this would be a pre-hackathon requirement once the direction is settled :-) > > On 5 Jun 2019, at 18:25, M. Ranganathan wrote: > > > > There is going to be a "hackathon table" for IETF 105. Here are some > ideas that occurred to me: > > > > - Quarantine : Mechanisms to isolate devices that violate MUD-specified > ACEs. > > For hacking=E2=80=A6 we need to have a good feel for the starting point i= n terms > of how to code. There was a draft we were discussing earlier (authored by Michael Richardson). I made a correction and posted an update to this list. This looks like it=E2=80=99s tied to logging... > Not necessarily (at least not the way I was thinking about it). It is a mechanism to identify a list of MUD ACEs that are operational for a MUD-enabled device that violates its intended behavior. > > - Logging and Event notifications : If a MUD-enable device violates its > allowed behavior, one approach is to summarize the violations and send > event notifications to some centralized event-gathering point. What to > report and to whom? Should we incorporate rate specifications so excessiv= e > connections or packet rates can be logged and notified. > > Right. What=E2=80=99s the reporting mechanism? I=E2=80=99m working on a= draft for this > now, which I will be happy to share in a week or two. We will need a MUD > extension for this (the reporting address). Michael and I were going bac= k > and forth about this. I do not want to simply say, =E2=80=9CURI=E2=80=9D= because there are > too many schemes out there. We know that email has to be one approach. = Do > we want RESTful interfaces as well for these reports? > Restful interfaces would be the most useful. You could, thereby generate an alert. Also what should be the format for these reports? IPFIX? > > > > Any other candidates? > > > > > > > > -- > > M. Ranganathan > > > > -- > > Mud mailing list > > Mud@ietf.org > > https://www.ietf.org/mailman/listinfo/mud > > --=20 M. Ranganathan --0000000000009da82e058a9f865c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Eliot,

On Wed, Jun 5, 2019 at 12= :54 PM Eliot Lear <lear@cisco.com&= gt; wrote:
Hi Ra= nga,

Validating and cleaning up Mudmaker.=C2=A0 For these below.

I'd say this would be a pre-hackathon requirement= =C2=A0 once the direction is settled :-)


> On 5 Jun 2019, at 18:25, M. Ranganathan <mranga@gmail.com> wrote:
>
> There is going to be a "hackathon table" for IETF 105. Here = are some ideas that occurred to me:
>
> - Quarantine : Mechanisms to isolate devices that violate MUD-specifie= d ACEs.

For hacking=E2=80=A6 we need to have a good feel for the starting point in = terms of how to code.=C2=A0

There was a dr= aft we were discussing earlier (authored by Michael Richardson). I made a c= orrection and posted an update to this list.


=
This looks like it= =E2=80=99s tied to logging...

Not neces= sarily (at least not the way I was thinking about it). It is a mechanism to= identify a list of MUD ACEs that are operational for a MUD-enabled device = that violates its intended behavior.


> - Logging and Event notifications : If a MUD-enable device violates it= s allowed behavior, one approach is to summarize the violations and send ev= ent notifications to some centralized event-gathering point. What to report= and to whom? Should we incorporate rate specifications so excessive connec= tions or packet rates can be logged and notified.

Right.=C2=A0 What=E2=80=99s the reporting mechanism?=C2=A0 I=E2=80=99m work= ing on a draft for this now, which I will be happy to share in a week or tw= o.=C2=A0 We will need a MUD extension for this (the reporting address).=C2= =A0 Michael and I were going back and forth about this.=C2=A0 I do not want= to simply say, =E2=80=9CURI=E2=80=9D because there are too many schemes ou= t there.=C2=A0 We know that email has to be one approach.=C2=A0 Do we want = RESTful interfaces as well for these reports?

Restful interfaces would be the most useful. You could, thereby gene= rate an alert. Also what should be the format for these reports? IPFIX?


>
> Any other candidates?
>
>
>
> --
> M. Ranganathan
>
> --
> Mud mailing list
> Mud@ietf.org
> https://www.ietf.org/mailman/listinfo/mud



--
M. Ranganathan

<= /div>
--0000000000009da82e058a9f865c-- From nobody Thu Jun 6 06:49:26 2019 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 530CF120161 for ; Thu, 6 Jun 2019 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 0tXGWqgLO3Qx for ; Thu, 6 Jun 2019 06:49:19 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB9512021F for ; Thu, 6 Jun 2019 06:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3288; q=dns/txt; s=iport; t=1559828958; x=1561038558; h=from:mime-version:subject:message-id:date:to; bh=UdzF2+zO2uvpn0isPMNn5YAKn+1VWoXU/Oacg+y9WBc=; b=I31DykM6cZ1xX3UHaeGKlR9GvsSp6rNYq69wZCmgcVDwQdLjdcXb8kSC 0zuP1hAQuVvxDN06Sr+9znoZLAptUlXDXe834iomss1j1ohiRCDLO+TOH QOIxOyke8IMLs9DJfGFTf9v+UA5tv0o26dA8fTMY2/h+NteVj1R2k2eW0 U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhAACwGPlc/xbLJq1lHQEBBQEHBQG?= =?us-ascii?q?BUQgBCwEBgnlRASASKIQUiBxfi16TBIYAgXsCBwEBAQkDAQEbFAEBh0g0CQ4?= =?us-ascii?q?BAwEBBAEBAgEEbRwMQgEMAYUZC3UBPQKEFAGCCpgXjnuBMYodEIE0AYFPiiK?= =?us-ascii?q?Bf4E4DBOCHwGFe4I9MoImBIwHh3uVFwmCEAOCGIEGgyKMehuCI2mGDoNdihG?= =?us-ascii?q?gOIMGAgQGBQIVgU84gVgzGggbFWUBgkEJNYpVhUE9AzCIVoRdK4IlAQE?= X-IronPort-AV: E=Sophos;i="5.63,559,1557187200"; d="asc'?scan'208,217";a="12865885" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jun 2019 13:49:16 +0000 Received: from [10.61.210.184] ([10.61.210.184]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x56DnFJb031825 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Jun 2019 13:49:16 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_73AF3D5B-EFC1-4D54-B91F-5625352EBBF8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <4E471F15-97F1-4769-90FD-B46926B6EED4@cisco.com> Date: Thu, 6 Jun 2019 15:49:15 +0200 To: mud@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.210.184, [10.61.210.184] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Mud] Mud hackathona areas of interest 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, 06 Jun 2019 13:49:25 -0000 --Apple-Mail=_73AF3D5B-EFC1-4D54-B91F-5625352EBBF8 Content-Type: multipart/alternative; boundary="Apple-Mail=_0C6656C0-A02C-498C-9357-62A5AB2CEDD7" --Apple-Mail=_0C6656C0-A02C-498C-9357-62A5AB2CEDD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shortly you=E2=80=99ll see a survey request for this. If you have = topics you would like to add, could you please forward them to me? To date I have the following: Build out validation capabilities based on packet traces for = mudmaker.org Test some IoT devices to build out mud files for them (BYOIOT) Build out any additional mudmaker capabilities (make some proposals) Build out vendor reporting capability (a'la ARF) Interop test / demo of multiple implementations using the same MUD file = with different implementation strategie For each of these there are some people who have shown interest already. = For some, some spec will be needed, or we will spend our time together = spec writing. Eliot --Apple-Mail=_0C6656C0-A02C-498C-9357-62A5AB2CEDD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shortly you=E2=80=99ll see a survey request for this. =  If you have topics you would like to add, could you please forward = them to me?

To date = I have the following:
  1. Build out validation capabilities based on packet traces for = mudmaker.org
  2. Test some IoT devices to build out mud files for them = (BYOIOT)
  3. Build out any additional mudmaker = capabilities (make some proposals)
  4. Build out vendor = reporting capability (a'la ARF)
  5. Interop test / demo = of multiple implementations using the same MUD file with = different implementation strategie

For each of these there are some = people who have shown interest already.  For some, some spec will = be needed, or we will spend our time together spec writing.

Eliot
= --Apple-Mail=_0C6656C0-A02C-498C-9357-62A5AB2CEDD7-- --Apple-Mail=_73AF3D5B-EFC1-4D54-B91F-5625352EBBF8 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXPkZ2wAKCRBugA9nE248 uM9NAJ4rFvEsTVMsTVmmUTOj/DEaWnRfagCg4lbS3wyLdaprtQ0zxv3kNXgTdXU= =nF59 -----END PGP SIGNATURE----- --Apple-Mail=_73AF3D5B-EFC1-4D54-B91F-5625352EBBF8-- From nobody Thu Jun 6 23:37:47 2019 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 7AA9812016A for ; Thu, 6 Jun 2019 23:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 MOVjQ3_RbHL1 for ; Thu, 6 Jun 2019 23:37:43 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029D6120123 for ; Thu, 6 Jun 2019 23:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=752; q=dns/txt; s=iport; t=1559889463; x=1561099063; h=from:mime-version:subject:message-id:date:cc:to; bh=zxU2GusadRVNOl9VZziuiIZsN6903f1SIr8qTnmNB48=; b=FmsdH2BF/FuxLexeqH3nP6isFK4NvCP7h5m7u3kDbxfI/D7UiVXWNcD5 vwO0ZP29eB0tZasTFTSiETMBRS0/Ed9CmZfZpltQilhi1vFIKhL5r3ArN SctvcwXT4M/R0sLLN466Vt5iMoY3oCrNsCrR385AwMq0PupYZO54zcPns w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAABmBfpc/xbLJq1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYJ6UjKMWV+kZoF7AgcBAQEJAwEBHxABAYRAgwg0CQ4?= =?us-ascii?q?BAwEBBAEBAgEEbRwMhWlhhHMBggoPqEKEMgGFdQoGgTQBgU+FNIRugX+BOB+?= =?us-ascii?q?DCoURgm+CJgSUApUXCYIQghuBBpAcG4ITAQ+Gd41xoDmDBgIEBgUCFYFPOIF?= =?us-ascii?q?YMxoIGxVlAYJCPYVBilU9A5ApAQE?= X-IronPort-AV: E=Sophos;i="5.63,562,1557187200"; d="asc'?scan'208";a="12891545" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jun 2019 06:37:40 +0000 Received: from ams3-vpn-dhcp2071.cisco.com (ams3-vpn-dhcp2071.cisco.com [10.61.72.23]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x576bd1h016247 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Jun 2019 06:37:40 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_97604820-81A6-4313-8249-BCF7023FB43A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 7 Jun 2019 08:37:37 +0200 Cc: "Grayeli, Parisa" To: mud@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.72.23, ams3-vpn-dhcp2071.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Mud] As threatened: survey for MUD hackathona work 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, 07 Jun 2019 06:37:46 -0000 --Apple-Mail=_97604820-81A6-4313-8249-BCF7023FB43A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Please take a moment to express an interest. https://www.surveymonkey.com/r/9WTR8HC Eliot --Apple-Mail=_97604820-81A6-4313-8249-BCF7023FB43A 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXPoGMQAKCRBugA9nE248 uJE4AJsFamowo5zRnjZnl4zGmmhJp9Rf9QCfd/tjQ4drx9w8S8GjBatZlyeOM+Q= =pbmw -----END PGP SIGNATURE----- --Apple-Mail=_97604820-81A6-4313-8249-BCF7023FB43A-- From nobody Fri Jun 7 09:53:21 2019 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 289E012011C for ; Fri, 7 Jun 2019 09:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ex3JSQ7MpO3I for ; Fri, 7 Jun 2019 09:53:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EB5120112 for ; Fri, 7 Jun 2019 09:53:16 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 0320938189 for ; Fri, 7 Jun 2019 12:51:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A803EF2A; Fri, 7 Jun 2019 12:53:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A5A2A9B0 for ; Fri, 7 Jun 2019 12:53:14 -0400 (EDT) From: Michael Richardson To: mud@ietf.org X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] new ways to get MUD files 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, 07 Jun 2019 16:53:20 -0000 --=-=-= Content-Type: text/plain I've been thinking about the Echo/Home/Mycroft systems of smart speakers, and how they learn new things via "skills". This makes it very difficult to write MUD for them, since they can expand their abilities. Yet, given the complexity of the devices, they are probably more risks associated with compromises of such devices. Mycroft I is ubuntu running on an RPI. It seems to me that each skill ought to come with a MUD file. There are a number of issues: 1) how does the MUD extension for the new skill get communicated to the firewall? 2) how do we know the new description is legitimate, and not part of the attacker's "profile"? 3) how do we identify which skill a communication is associated with? 4) how do we engage with these vendors? My IPv6 take is that each skill should have a different IPv6 address. This could trivially be done by putting each skill into a container. If you go that way, then it could work in IPv4 with DHCP+MUD-url within each skill, but 256 IPs might not be enough for some people, which is why IPv6 makes it so much easier and obvious. (*Linux* containers with name spaces, don't have to be split off everything, just doing the network namespace is enough. The rest of the system can be unified) 5) can we communicate MUD URLs without DHCPv6? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz6lnoACgkQgItw+93Q 3WUAXAf+JSmox8BkYoXK/ijalbslL3GBYC+LcB6kZ+T6Gt2Ig+xYlMx3sGHgCbvd ibgMh1ZQEFs3Hg4w4IgKGkJpXJ+NHv3MAvSKssV3WMB8qzyapddByPXDf2t/TSdq MWMN8qgv7vAmo/KUssVVUYwF+Fd0cBirLgILoGkdXUl2WEaT+d8byJWBHIwLOQCh 1s+k386T4n/u71cWZnF3J03RjZlcceUDlU4XRwS75w3ROyP0KLbUVKDEktSdVoAN V0LqeYShMKGH+RRWulueASw4Iy0rXw+69NXTWzHSscZjwFVjHIWTEDUW6wi/vtyg 1oUGJ8DGOeAMgqYOZhayt2XSypesrQ== =a1oS -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 7 10:17:58 2019 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 0FCFB1200F4 for ; Fri, 7 Jun 2019 10:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jhXImyfJ3xsj for ; Fri, 7 Jun 2019 10:17:55 -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 6A5D9120020 for ; Fri, 7 Jun 2019 10:17:55 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id k20so1975341ios.10 for ; Fri, 07 Jun 2019 10:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TZHlOeBl4Lg3SRN3uFlTl4pStdQoNzhp2WUwd2jKJeI=; b=LXGQCuDJr3F4eEGgYYvQRKHRCRw8/1dkuU9AxZJJVk99x4/Z0jLZ9n83mC4gw/COUT jYKnu4h7a8Las2Y1zeLKaF0tPDNpK0HKyJf0uehsgIBtdeFJ2hhfTlqtreIold1mD/AK Q07bz0n8xJHRJsMSQBA52Xcf+KmIOxikOECn2AtYXpG0/J03cKpCuJQ33J3uu9ufUrNA TgVlViKtPI9+ZXhdBRp/0GTm9eV/m9W7v0lgu19ovPHs3mVlMcASlSUNQ9TpJL444cdX 03UGIeS26ve7d0U1lEXnR0u+JZfnU/ihNYHFDs0k95jFfO8vaENUdz+B10vUBOxTTUNB EZbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TZHlOeBl4Lg3SRN3uFlTl4pStdQoNzhp2WUwd2jKJeI=; b=eFuJxx5s7oY7W9AO9wnTI2S/kP/T9PWtOJIYwK9QitFZgrr5D1YRe4h08ZJ8i4iCTG bwXez1oDWlqTl7eB7bRQa3Y3nA4M2PtqjOozb8ATMZZJbRB/FwKZF6A++4sK8H51tYNt zgD88ExGuxRrBdWhw4iVhgEqqVlztn+qQz6JVb3vl3bF0qb7oQVJfea097QGFg1LixqP j9+zLjAHAjOkcE9g5m/eAubhlM89J0NciVgW5wKWT+3dIJT9LbWuWmxCc/XnM/AVEoH0 fG4WKjZGiHRHJjtwmaj2RpUU/JLUGX3Z8p8rusU8QOeLoFNFWJL4anNMlINhT6Cm9qcf H70A== X-Gm-Message-State: APjAAAWvpeGAN+ptXX5YKAErHQ78HqsFDmoKsuTBNrYKQ8KSZaVHH0XM RjB4pSDjJ+DxY4wE07H+MJXhT7Oj6b++Kcu9Biu+DZE7 X-Google-Smtp-Source: APXvYqylZYZdfSh75X19xyuV55AbqwHaOmxsRzJMRW2uXj8aCh0kz4JM74XrpLgek0A4q2PZoNR2ionv+GtkzGP5+kU= X-Received: by 2002:a6b:b790:: with SMTP id h138mr31452603iof.64.1559927874230; Fri, 07 Jun 2019 10:17:54 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Fri, 7 Jun 2019 13:17:17 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1a156058abf02f8" Archived-At: Subject: [Mud] Controller and MyController secure registration 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, 07 Jun 2019 17:17:57 -0000 --000000000000d1a156058abf02f8 Content-Type: text/plain; charset="UTF-8" Controller and my-controller mechanisms are defined to allow the device to talk to classes of devices which register themselves as controllers. The MUD specification leaves out the mechanism on how Controller and my-controller will be defined other than to say that this is an administrator concern. While several mechanisms are possible for secure registration (identity based perhaps), should we pick one for interoperability purposes. eg. if a manufacturer ships a controller for his devices, how will that controller know how to register itself with the mud manager? Ranga -- M. Ranganathan --000000000000d1a156058abf02f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Controller and my-controller mechanisms are defined t= o allow the device to talk to classes of devices which register themselves = as controllers.

The MUD specification leaves = out the mechanism on how Controller and my-controller will be defined other= than to say that this is an administrator concern.

While several mechanisms are possible for secure registration (identity b= ased perhaps), should we pick one for interoperability purposes. eg. if a m= anufacturer ships a controller for his devices, how will that controller kn= ow how to register itself with the mud manager?

Ra= nga

--
M. Ranga= nathan

=
--000000000000d1a156058abf02f8-- From nobody Fri Jun 7 10:28:02 2019 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 4A497120131 for ; Fri, 7 Jun 2019 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 WxrQi5Y3r1P8 for ; Fri, 7 Jun 2019 10:27:59 -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 38A141200F4 for ; Fri, 7 Jun 2019 10:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1947; q=dns/txt; s=iport; t=1559928478; x=1561138078; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=/VMUizrZpO60zs95+x65RmwNloJWTW+05mvqRljBuTQ=; b=Yadp+L5Kms1bTln+0OU8pNCoaLMD11Bby5z6EnOn3gqaQ1VgTBY5m4Z6 hercobimmN9N/3WuvQdhFXTPx20nMesz00qFSUM5rxUycZcB/UbDST46M Fvnoci5HT0Z42jm3UqcV05voiyHe8YEjJz30R+R2FJUGRIEtYtqSnppTN 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAonvpc/xbLJq1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgnpSIBIohBWIHF+LYiWJQ48cgXsCBwEBAQk?= =?us-ascii?q?DAQEYCwwBAYRAAoMNNAkOAQMBAQQBAQIBBG0cDIVKAQEBAQIBAQEhSwsFCws?= =?us-ascii?q?YKgICIQYwBhODIgGBagMODw+nc4ExhUeCPw2CEwoGgTQBgU+KIoF/gTgME4I?= =?us-ascii?q?eLj6CGkcBAYE3gzQygiYEi22IGJRhPgmCEIIbgQaMNYNrG5cRlgSKOoMHAgQ?= =?us-ascii?q?GBQIVgU84gVgzGggbFTsqAYJBPoFYiH2FQT0DMJA1AQE?= X-IronPort-AV: E=Sophos;i="5.63,563,1557187200"; d="asc'?scan'208";a="12848057" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jun 2019 17:27:56 +0000 Received: from ams3-vpn-dhcp2071.cisco.com (ams3-vpn-dhcp2071.cisco.com [10.61.72.23]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x57HRtqk017340 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Jun 2019 17:27:56 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F5AD999E-D9BB-4BBD-A805-32CDAF6F18C8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 7 Jun 2019 19:27:54 +0200 In-Reply-To: Cc: mud@ietf.org To: "M. Ranganathan" References: X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.72.23, ams3-vpn-dhcp2071.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] Controller and MyController secure registration 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, 07 Jun 2019 17:28:01 -0000 --Apple-Mail=_F5AD999E-D9BB-4BBD-A805-32CDAF6F18C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ranga, Right now for those abstractions it=E2=80=99s manual. But I do think = it=E2=80=99s good to look at standardizing how controllers can register = with the MUD manager, for ease of selection. We=E2=80=99ve looked at = this a bit at Cisco. That leads to a discovery discussion (how to find = the MUD manager) or whether to create a new certificate attribute, or = what. This would be a good discussion for MUD side meeting. Eliot > On 7 Jun 2019, at 19:17, M. Ranganathan wrote: >=20 > Controller and my-controller mechanisms are defined to allow the = device to talk to classes of devices which register themselves as = controllers. >=20 > The MUD specification leaves out the mechanism on how Controller and = my-controller will be defined other than to say that this is an = administrator concern. >=20 > While several mechanisms are possible for secure registration = (identity based perhaps), should we pick one for interoperability = purposes. eg. if a manufacturer ships a controller for his devices, how = will that controller know how to register itself with the mud manager? >=20 > Ranga >=20 > -- > M. Ranganathan >=20 > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud --Apple-Mail=_F5AD999E-D9BB-4BBD-A805-32CDAF6F18C8 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXPqemgAKCRBugA9nE248 uFQLAJ91gbAuthdwXkNvKmCq9WZerrBPHwCggdkO8kLVUOZu1LgpvrkepP3FPVg= =e73t -----END PGP SIGNATURE----- --Apple-Mail=_F5AD999E-D9BB-4BBD-A805-32CDAF6F18C8-- From nobody Fri Jun 7 10:48:24 2019 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 263261200B4 for ; Fri, 7 Jun 2019 10:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Zh6jAt3Hx7by for ; Fri, 7 Jun 2019 10:48:19 -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 EE660120020 for ; Fri, 7 Jun 2019 10:48:18 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id k13so2058695iop.5 for ; Fri, 07 Jun 2019 10:48:18 -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=jACG5qqpkhGYfe3giBbIZBoGtPlHZNhxSL6aJgXo+xE=; b=OndchPAhGe0k++TqLI3tTCC7Rs1X6JKb2yHZn4pLbtuxcPTgFxVJHMSrkX/Cj5yC+U mdgKwdDP2s0Umb5JyILRec+xtwRsLvGBw4emI28hTgTkvRSxIJy1Nz9zyy4+16Lx6jUP XLIyc9I0LSjFoLLCZ7yAgPsqqwG/TYzUqwq+iUJ38FXiPeg9HPTgGq8SiDYMUAZDwErO pOydZMkqB/vIxb1V/ESdFPMtFvstxEz4zMdEhIrNP4jnKtTKSSBCsa4tAXuLl0h+LkU+ vfsh72Xke1AkRGERs//qA1GCh88bcTw0A4nJMrhyKMzagwIlL6Xg922Fav1GV61WAV2D boqw== 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=jACG5qqpkhGYfe3giBbIZBoGtPlHZNhxSL6aJgXo+xE=; b=mHAXLEv7rPal9Q9lt25k3lFA2qZ7L1s5Xjs0zWLlZKvAu2m9UXv5LsKoaxp+b0yeRV OiSINz/kG+0aElGdJbbf0Dq02f6cCrjpTH5w1XPsNfl2nS4clLoOxhvBHaHlo+iZrLhK dmxmU5TKBwuf4pIhMOgboOGDiEJPgc3F939pdQ4SW7/9O8enowThdcokGMb+jHz11E5Z nDbFtT4l5zbn8amA6ZqD+Fy7V3gbPgYJg6qYpJ9L6B4cYJQZWVc14ijGAZTsMA/J5JDS 9E2aReutLo1jsb3M8KvPFaqTgz3Ci4gPiAsM7vWWmpazAY5z8KnDQPkgNxz0aF7eAV2o jssA== X-Gm-Message-State: APjAAAVyoa/Y8QfD3noo2ezDR6/klGv9lzeHZiX++1uiUBX/B7veG9gf uMEsG2i/UqQjcBodFs72Mcxu1UvKqsP1cOQlU68= X-Google-Smtp-Source: APXvYqwiE59StDrv1QqCGaWLQHkkDScxK8234kelEso/UB4GSj2+Rqp+wiX4ZOY4r34QFPqBYeIk8ryT8UHVqDjVNDI= X-Received: by 2002:a5d:9448:: with SMTP id x8mr31092985ior.102.1559929698014; Fri, 07 Jun 2019 10:48:18 -0700 (PDT) MIME-Version: 1.0 References: <17359.1559926394@localhost> In-Reply-To: <17359.1559926394@localhost> From: "M. Ranganathan" Date: Fri, 7 Jun 2019 13:47:41 -0400 Message-ID: To: Michael Richardson Cc: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000865ebc058abf6fa9" Archived-At: Subject: Re: [Mud] new ways to get MUD files 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, 07 Jun 2019 17:48:22 -0000 --000000000000865ebc058abf6fa9 Content-Type: text/plain; charset="UTF-8" Hello Michael, Do these new skills result in changes in communication patterns (I don't know how this works and hence I ask)? If there were a way to dynamically invalidate an existing MUD file and register a new one with the mud controller dynamically, would that address this use case? This could be accomplished as follows: - Device violates its MUD profile - Mud Manager gets informed of it. - Mud Manager contacts manufacturer web site with a log of the events that lead up to the violation. - Mud Manager fetches a new profile if appropriate and installs it. This would require standardizing the interaction and logging / event notification format to send to the manufacturer so the manufacturer has enough information to make this decision. Perhaps a subject for discussion. On Fri, Jun 7, 2019 at 12:53 PM Michael Richardson wrote: > > I've been thinking about the Echo/Home/Mycroft systems of smart speakers, > and > how they learn new things via "skills". This makes it very difficult to > write MUD for them, since they can expand their abilities. > Yet, given the complexity of the devices, they are probably more risks > associated with compromises of such devices. Mycroft I is ubuntu running > on > an RPI. > > It seems to me that each skill ought to come with a MUD file. > There are a number of issues: > 1) how does the MUD extension for the new skill get communicated to the > firewall? > > 2) how do we know the new description is legitimate, and not part of the > attacker's "profile"? > > 3) how do we identify which skill a communication is associated with? > > 4) how do we engage with these vendors? > > > My IPv6 take is that each skill should have a different IPv6 address. > This could trivially be done by putting each skill into a container. > > If you go that way, then it could work in IPv4 with DHCP+MUD-url within > each skill, but 256 IPs might not be enough for some people, which is why > IPv6 makes it so much easier and obvious. > > (*Linux* containers with name spaces, don't have to be split off > everything, > just doing the network namespace is enough. The rest of the system can > be unified) > > 5) can we communicate MUD URLs without DHCPv6? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > -- M. Ranganathan --000000000000865ebc058abf6fa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Michael,

Do these new = skills result in changes in communication patterns (I don't know how th= is works and hence I ask)?

If there were a wa= y to dynamically invalidate an existing MUD file and register a new one wit= h the mud controller dynamically, would that address this use case? This co= uld be accomplished as follows:

- Device violates = its MUD profile
- Mud Manager gets informed of it.
- Mu= d Manager contacts manufacturer web site with a log of the events that lead= up to the violation.
- Mud Manager fetches a new profile if appr= opriate and installs it.

This would require standa= rdizing the interaction and logging / event notification format to send to = the manufacturer so the manufacturer has enough information to make this de= cision. Perhaps a subject for discussion.

On Fri, J= un 7, 2019 at 12:53 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I've been thinking about the Echo/Home/Mycroft systems of smart speaker= s, and
how they learn new things via "skills".=C2=A0 =C2=A0This makes it= very difficult to
write MUD for them, since they can expand their abilities.
Yet, given the complexity of the devices, they are probably more risks
associated with compromises of such devices.=C2=A0 Mycroft I is ubuntu runn= ing on
an RPI.

It seems to me that each skill ought to come with a MUD file.
There are a number of issues:
=C2=A0 1) how does the MUD extension for the new skill get communicated to = the
=C2=A0 =C2=A0 =C2=A0firewall?

=C2=A0 2) how do we know the new description is legitimate, and not part of= the
=C2=A0 =C2=A0 =C2=A0attacker's "profile"?

=C2=A0 3) how do we identify which skill a communication is associated with= ?

=C2=A0 4) how do we engage with these vendors?


My IPv6 take is that each skill should have a different IPv6 address.
This could trivially be done by putting each skill into a container.

If you go that way, then it could work in IPv4 with DHCP+MUD-url within
each skill, but 256 IPs might not be enough for some people, which is why IPv6 makes it so much easier and obvious.

(*Linux* containers with name spaces, don't have to be split off everyt= hing,
just doing the network namespace is enough.=C2=A0 The rest of the system ca= n
be unified)

5) can we communicate MUD URLs without DHCPv6?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud


--
M. Ranganathan

<= /div>
--000000000000865ebc058abf6fa9-- From nobody Fri Jun 7 12:56:14 2019 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 D10BC120131 for ; Fri, 7 Jun 2019 12:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhwN0_Cs8yJK for ; Fri, 7 Jun 2019 12:56:11 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C752120092 for ; Fri, 7 Jun 2019 12:56:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A05803818B; Fri, 7 Jun 2019 15:54:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7CA11F60; Fri, 7 Jun 2019 15:56:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 785B7B22; Fri, 7 Jun 2019 15:56:09 -0400 (EDT) From: Michael Richardson To: Eliot Lear , "M. Ranganathan" , mud@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Controller and MyController secure registration 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, 07 Jun 2019 19:56:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable First, I didn't really pay a lot of attention to the controller portion of the specification. Eliot Lear wrote: > Right now for those abstractions it=E2=80=99s manual. But I do think= it=E2=80=99s good > to look at standardizing how controllers can register with the MUD > manager, for ease of selection. We=E2=80=99ve looked at this a bit a= t Cisco. > That leads to a discovery discussion (how to find the MUD manager) or > whether to create a new certificate attribute, or what. I think that when the controller communicates it's MUD URL to the mud-manager, the MUD file should declare it to be a controller. I would like to further consider specifying something in or around BRSKI about this as well. (Could be an IDevID extension, could be an BRSKI-EST API extension) Clearly the device needs to be clear about what kind of controller it talks to, and I don't know how this works right now. There could also be a multitude of controllers (a lighting controller for each floor for instance) From=20the same vendor. Do controllers get to talk to controllers? > This would be a good discussion for MUD side meeting. I agree. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz6wVkACgkQgItw+93Q 3WWmigf/ffvmuZBOoD7LmDpCi5eUJ+A09HRKYABLwAMm8ZJaN3BpocQ4oWyyDpas e+aV8bsRJV23qyoEraMhmnt0Am3KZI/Lvd1LLQQzLD2vKoY5re/FMO9Jmf16ijmS g6ESMkXQ7DE7NRLuSfozu3Dw8fmBuikBuLht91sTPl/BhKaZ1+6LRWqdO++gkePx HgbIR1CBwSsrZkRMScwT6Rf4litKTg4z2IwL3keY2W+tG88xkOdBwue7PlIzSkLa cSRHIiZqksbtES8BPt44S99OEfqJ/D3ZiXv0LaizdoOGejc11a3wwG3yOy4H3OMO wptpWFS640WHRgYTjVJn5fdkCiYDcA== =BgQd -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 7 13:15:18 2019 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 6A58D1201B4 for ; Fri, 7 Jun 2019 13:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a7ftNOu4xgr for ; Fri, 7 Jun 2019 13:15:15 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8427712016B for ; Fri, 7 Jun 2019 13:15:15 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E28F43818C; Fri, 7 Jun 2019 16:13:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B92FCF60; Fri, 7 Jun 2019 16:15:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B68819B0; Fri, 7 Jun 2019 16:15:11 -0400 (EDT) From: Michael Richardson To: "M. Ranganathan" cc: mud@ietf.org In-Reply-To: References: <17359.1559926394@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] new ways to get MUD files 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, 07 Jun 2019 20:15:18 -0000 --=-=-= Content-Type: text/plain M. Ranganathan wrote: > Do these new skills result in changes in communication patterns (I don't > know how this works and hence I ask)? yes, if you add the "Phillips Hue" skill, then the device can talk to your light bulbs. > If there were a way to dynamically invalidate an existing MUD file and > register a new one with the mud controller dynamically, would that address > this use case? This could be accomplished as follows: > - Device violates its MUD profile > - Mud Manager gets informed of it. > - Mud Manager contacts manufacturer web site with a log of the events that > lead up to the violation. > - Mud Manager fetches a new profile if appropriate and installs it. No, it wouldn't because the either new file would not be signed, or you'd need to N! MUD files for N skills. And anyone can write a skill, btw. > This would require standardizing the interaction and logging / event > notification format to send to the manufacturer so the manufacturer has > enough information to make this decision. Perhaps a subject for discussion. I agree that all of these are important, and I want to work on them! I just don't think that it helps for the smart-speaker. In case I didn't share my RIPE IoT non-presentation, it is here: https://www.youtube.com/watch?v=GOmHx8jpaCM A different setup, but similar results, would be for a Zwave or Bluetooth gateway. As you add new devices (on Zwave, not IP), then the set of allowable transactions might change. That's probably far more constrained than the skills problem, but it still seems like an issue. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz6xc8ACgkQgItw+93Q 3WWJPAf9Hx4RYucYDWvTJZUmIfCquGfTIFvxVyCYClQ8fARRS4mF41f98W3QHz7y 4O/bX1PBLXujwHzgGGKR2DCEWgB++MQuKj5uYsEtPCP8km+ZhrsqaeL3b+SBXfnK zFj5jI1kPeigSxUStbxyh9XsSU+BFns9OXBcV/PawmVIY/Q0h0a6NTNvaPC9ZPQZ MameyBPJ2/jMaWrT/69BKGSRiEj1D1LdouZQHsjc/yu36inSSPkzOxKtGTjeYrzh Nmwq0yVBG9i7rOdpfuYqD7qpIVWi3CWbKag8JryQh6mWd++eOw1arUfRM+XsueEg syEYtP1ctm+afyGsGvN3s5lNGe+Yqg== =G6h8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 8 17:42:23 2019 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 48FAB120105 for ; Sat, 8 Jun 2019 17:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tArzQYczzON9 for ; Sat, 8 Jun 2019 17:42:19 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 96B1612011E for ; Sat, 8 Jun 2019 17:42:19 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id q14so7171827itc.5 for ; Sat, 08 Jun 2019 17:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ulBXsWclffX/F2GaDEOFfySvTMCCS9vBP/XdDI5QU5c=; b=kLKT5XEsIMtNUsCkd0dGnUoXgAkm7GFY3DDQvEm0Yx0BW0IiucSSVlyXvgiv2cIRvt Vb8NUmqABnFvRfsnQxqXS0gxzD8VZrhmgreg9fys1Z+/pjmYqJulaqBmg85AluwUdxlG 2sv25wK9U5VbAiTXXBhek9hOB/cI8aANuFQqSBkIuhmAr+GqQG3q7EAzRWGlEyqIqBZF c/3ajx16Q18ZHactk8OVjXnqh+1VLMWU8TNkX3HGwyVup2m9/v2POdml1gPfT/MKJNIs VJtrgLC6usfneiOxjoebK1soEpNiQAHJs+KxyFoemNsdITVYAhT7nq0FuJEl6AbEA3r0 j3eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ulBXsWclffX/F2GaDEOFfySvTMCCS9vBP/XdDI5QU5c=; b=ce5Qg35NASzyPRa//2PmoDnlpQrFdO/ayF20pPnAMVQaOcYmItQRbaVd84YWvaTYVT ug6T7v5n7ry95Jn0qyhESQAxmksOAHNZj6fsw8zAqs/jlx2NgiJlLkZxVWWAQig8HMC3 eMpoYvY6TmIxfMFg3SmHO0sM9uw0abiCEBDu9DUZeSUspDtsg9XlODBVs5VISiajbShJ 5oKVHITW8S8JEMLZ6nTEdLDxzkd5oqIN/fpXso+iR2Izgq2YU4i2Y4T5kH0ZigDNCq8l 8de8gb2KlBcdACuoBrrmnMSb9a8ndRjGSn47WJKbmbdTpPDwVIMU2yJLOt5JGXSODuy+ aVtQ== X-Gm-Message-State: APjAAAUalOaWEnN8nnGSrdbprJXBC+QrxdShQiQC5b5pTymaqohBOnwi tgYjdntcrOOr43+uTiXxIzkPVb8UE9NxTRa+yQPHxKCPfi+Vog== X-Google-Smtp-Source: APXvYqyhiNbyFE1j3ahtVuBiuHoHY4SGwod/E5C2cgYgl1twWFDozkJnL+801IYkrCNXp7Me/mmHUiTLd6FF2PtaWgo= X-Received: by 2002:a02:b384:: with SMTP id p4mr39564465jan.125.1560040938350; Sat, 08 Jun 2019 17:42:18 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Sat, 8 Jun 2019 20:41:41 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000f72e46058ad955ca" Archived-At: Subject: [Mud] DHCP lease expiry 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: Sun, 09 Jun 2019 00:42:21 -0000 --000000000000f72e46058ad955ca Content-Type: text/plain; charset="UTF-8" What (if anything) should the mud server do with the device to MUD URL association when the DHCP lease expires? TIA for clarifications, Ranga -- M. Ranganathan --000000000000f72e46058ad955ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What (if anything) should the mud server do with the = device to MUD URL association when the DHCP lease expires?

TIA for clarifications,

Ranga

--
M. Ranganathan

=
--000000000000f72e46058ad955ca-- From nobody Sat Jun 8 18:06:53 2019 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 E2283120072 for ; Sat, 8 Jun 2019 18:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVd9Dq9It5-a for ; Sat, 8 Jun 2019 18:06:48 -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 82A2C120058 for ; Sat, 8 Jun 2019 18:06:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 570D138184; Sat, 8 Jun 2019 21:05:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D3B4BF28; Sat, 8 Jun 2019 21:06:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D12EEBDF; Sat, 8 Jun 2019 21:06:44 -0400 (EDT) From: Michael Richardson To: "M. Ranganathan" cc: mud@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] DHCP lease expiry 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: Sun, 09 Jun 2019 01:06:51 -0000 --=-=-= Content-Type: text/plain M. Ranganathan wrote: > What (if anything) should the mud server do with the device to MUD URL > association when the DHCP lease expires? Depends upon how things are index and firewalled. We are building firewalls based upon L2 (ethernet) addresses. So we keep them and we don't care about the L3 address. A malicious device can always lie easily about L3 addresses. And IPv6 privacy extensions are basically continuous "lies" L2 addresses are also easily changed, but doing so can invalidate the WIFI connection, so it seems less likely thing to do. So, I'd keep it. The device might be coming back. Perodically, maybe old devices (or old firewall entries) need to be purged. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz8W6QACgkQgItw+93Q 3WVXgAf9GIF00GAXiFe+YyNQLMZZyUziLWTFOCljqkPaCaUU+W+w3/Ld4U5vJW2M iyyNfYSWG/baUlrdwby1mGAdKxgAco2CCpWmzzyPoJcRmA0/RLRpbh1WvGfkrTCR nXYG/LiOGrzxHyqfqbCU5YH5f8HlcsnTlLHnD0nQf3xFt8bnOnKCva6FAlgli/uF KYpJ21MJuZXzg4sTuEpJLxRtlbwdOZT8bmWYDTt05BPW9tEj0kRk3nH9nbfZD+D7 9gsMHNWUFyUnwis/MyktYqIc1evQSW+GDDBsi7CaE8sGqPLjcZGOSdoKnbflQgW8 ar7Nw9Mia7kd8qY3wtsgbNhJocVEtg== =5rVx -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 12 11:05:25 2019 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 AE884120025 for ; Wed, 12 Jun 2019 11:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgL2mQfcjD6r for ; Wed, 12 Jun 2019 11:05:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867DE1200B1 for ; Wed, 12 Jun 2019 11:05:20 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 9513A38183 for ; Wed, 12 Jun 2019 14:03:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 668EB107F; Wed, 12 Jun 2019 14:05:19 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6532991F for ; Wed, 12 Jun 2019 14:05:19 -0400 (EDT) From: Michael Richardson To: mud@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] content-type for MUD files 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, 12 Jun 2019 18:05:25 -0000 --=-=-= Content-Type: text/plain RFC8520 does not as far as I saw, define a Content-Type for MUD files. I think that this is an additional to-do. I was thinking about the case of trying to enter a MUD URL into a UI (on mobile). Imagine people in an email list or some "phpBB" discussing the relative merits of various configurations, and someone wants to say, "try mine" and posts a URL. It would be nice if the MUD file came with a content type that a mobile app could register as belonging to it, such that it would take the URL/contents and do something useful with it. [At first, I was thinking that I'd want to have a URI type which would pass the URL to the APP, but then I realized that was overkill, that as long as the contents go there, great] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0BPt8ACgkQgItw+93Q 3WV+nwf/UizWLwMdQ3sTqkWBEhgDXUu9vws60cl6eVRo9UFFScJZFuCBYpwCYnrY bUJL6MLrtNwUe3jdOVhF2HYOvMTbRTtQSrsOLtGnuPgH5YSZkCWD/u6gdHhgDKnI amEmyq5QP+KutGeThQOSpmmlwvFWHxwqT4A3pF30yXgM/+3SB+0hY+QSRRGOvwNn nuVthmbworDG6whJYk/MXieX8QZyp1AoHLQqYKaSRQjXKQmZYdkUPMaPHPXbc3F9 9X4NNYGWu/uf1CuFblloWgVCFkfH82EueW9fzKOKH6tm5WIg0eC/6AkDNj63wYen vxmbRBu39zMJa9bynUMo6ZgU7LnJOA== =XD+Y -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 12 13:39:22 2019 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 2D74812017E for ; Wed, 12 Jun 2019 13:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 ZHXm7k8ESMVM for ; Wed, 12 Jun 2019 13:39:12 -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 60040120180 for ; Wed, 12 Jun 2019 13:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=945; q=dns/txt; s=iport; t=1560371942; x=1561581542; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=cH5KtkzH+0n0l6DnLatSINP8OeZf3As8qlh5Osiwrg8=; b=cxGyvHTc3PW/1WVSK9Js3e0+iAS+HcYAQPm6o6ZJBc9wJtYME1WDKC7v j+ysRaaaznthU7x/ye08RMymkaqmcfWFKNkAofDrjk8duB0aWXntxPPo+ eUeLE8SoBwrCqPf/w+WiRKw9+dnJrdkU60ibBH/OJgvulxuzLeFMUqBvX 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACXYgFd/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGDbBIohBWIHF+MBphhgXsCBwEBAQkDAQEvAQG?= =?us-ascii?q?EQAKCZzQJDgEDAQEEAQECAQRtKIVKAQEBAQIBI1YFCwsYKgICVwYTgyIBgXs?= =?us-ascii?q?PqgeBMYVHhFoQgTQBgU+KJIF/gTgfgkw+h04yggQiBJQYlSoJghKCG4EGkCk?= =?us-ascii?q?bghUBlRKgWYMIAgQGBQIVgU84gVgzGggbFWUBgkE+kBY9AzCQAAEB?= X-IronPort-AV: E=Sophos;i="5.63,367,1557187200"; d="asc'?scan'208";a="13026113" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jun 2019 20:38:58 +0000 Received: from ams3-vpn-dhcp2414.cisco.com (ams3-vpn-dhcp2414.cisco.com [10.61.73.110]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x5CKcvM0014726 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Jun 2019 20:38:58 GMT From: Eliot Lear Message-Id: <901002AC-14C0-41DE-AC96-1A709C9CF15B@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_187F94EA-CF72-4AFA-AAFE-7A15059C350E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 12 Jun 2019 22:38:57 +0200 In-Reply-To: <2441.1560362719@localhost> Cc: mud@ietf.org To: Michael Richardson References: <2441.1560362719@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.73.110, ams3-vpn-dhcp2414.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Mud] content-type for MUD files 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, 12 Jun 2019 20:39:15 -0000 --Apple-Mail=_187F94EA-CF72-4AFA-AAFE-7A15059C350E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jun 2019, at 20:05, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > RFC8520 does not as far as I saw, define a Content-Type for MUD files. > I think that this is an additional to-do. It=E2=80=99s in there. See Section 17.5. --Apple-Mail=_187F94EA-CF72-4AFA-AAFE-7A15059C350E 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQFi4QAKCRBugA9nE248 uJVOAJ9/wSMcQSej+JJK5Gnwj2TN6NttAgCfUXGI/EiNb8BRVb5FRpPfHwNojzc= =InzS -----END PGP SIGNATURE----- --Apple-Mail=_187F94EA-CF72-4AFA-AAFE-7A15059C350E-- From nobody Wed Jun 12 14:35:47 2019 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 52782120189 for ; Wed, 12 Jun 2019 14:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W39BL1_LNdji for ; Wed, 12 Jun 2019 14:35:43 -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 E37021200B2 for ; Wed, 12 Jun 2019 14:35:42 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E26CE380BE; Wed, 12 Jun 2019 17:34:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D0231169F; Wed, 12 Jun 2019 17:35:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CEB23107F; Wed, 12 Jun 2019 17:35:40 -0400 (EDT) From: Michael Richardson To: Ad Bresser , "mud\@ietf.org" In-Reply-To: References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <32236.1558976943@localhost> <19145.1559083385@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Unique credentials for devices in a home network 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, 12 Jun 2019 21:35:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ad Bresser wrote: mcr> Do we need to write an Operational BCP for IoT and DNS here? >> tirumal reddy wrote: >> > Yes, looks useful to me. >> >> could there be someone else who wants to write this? > To save some writing time: > The ICANN SSAC (Security and Stability Advisory Committee), published: > SAC105 The DNS and the Internet of Things: Opportunities, Risks, and = Challenges > https://www.icann.org/en/system/files/files/sac-105-en.pdf I read through it. I think that it is too positive about DoH: "As a result, it becomes more difficult to trick IoT devices into using a malicious resolver. This is kinda true. It also makes it hard to substitute a resolver that provides some filtering, or answers local names correctly, or which does not expose one's lookups to third party, if the IoT manufacturer has locked in the certificate of the D= oH resolver. This is useful background, and should be referenced, but I don't think it goes to core of how to do DNS well from an IoT device such that MUD can work well. From=20section 5, it says: > The challenges we identified are: > * Developing a DNS library for IoT devices (Section 5.1) that makes the > DNS=E2=80=99s security functions (e.g., DNSSEC validation and DoH/DoT) av= ailable > for device control applications and that uses DNS query data to make IoT > deployments more transparent for users (Sections 3.1, 3.2, and 3.4). It seems that ICANN might want to do development work here? > * Training IoT and DNS professionals (Section 5.2) to help DNS players su= ch > as registrars and registrants understand the implications of providing > services for domain names that act as a backend for IoT devices rather th= an > as a means for making content available to humans (Section 3.3), and to > help IoT device manufacturers understand how to use the DNS and how to > configure resolvers (Sections 4.1 and 4.3). I think that there is a missing element here, which is talking about DNS at IoT conferences, about the libraries one can use, but most importantly, abo= ut how to do DNS in a way that makes MUD easier to do. There is also a need to reach out to the CDN community, and deal with the question of names to IP mapping, and how we make sure that the name provides the service requested, and only that service. > * Developing a shared system that enables different DNS operators to > automatically and continually share information on IoT botnets (Section > 5.3), allowing them to more quickly respond to rapidly growing botnets and > the DDoS attacks they generate (Section 4.2). I see we get mentions: Examples of security systems for edge networks are SIDN Labs=E2=80=99 SPIN system [48= ], CIRA=E2=80=99s secure home gateway [59], and IIT/CNR=E2=80=99s NTOP system [60]. but, then I see that Jacques is a contributor! > * Developing systems that enable DNS operators to share DDoS handling > capacity and that stop attacks in an early stage in edge networks (Section > 5.4), so DNS operators can better handle very large (amplified) IoT-power= ed > DDoS attacks (Sections 4.2 and 4.3). > * Developing a system that enables DNS operators to measure how the IoT > uses the DNS (Section 5.5), to better understand how IoT risks evolve > (Section 4)=E2=80=94for instance to develop new domain name policy or for= incident > response purposes. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0BcCwACgkQgItw+93Q 3WWEvggAukeI2cX9C9euv2JWx5BUmczSURwgBQFwzt2cd3bvqkDl+uWHIkhrgyEV pdKgSofHRY9LOnZHwkLfRcGKgf1+btTJxVRs6uXUNi9Z26qZuzOSY4SOxFWSbW11 dgvPdA/gbDetzqPnZAzuf6kuPf3laO+Ujn7Tt04Fp3SILyx0J+yHkb3jbNdEoc+j qQ9XDiee0LJOWxuFGqr7arDaNAHcY7uDKq/PbIgHGAYi4g3guafgvo4ZHyjzKc8H bhCQcGp59ecluMklmaTHohw1Y3gkA8TgZHjNog30y9TkbPNwsXEqAFtbQE95a3Tz nNOWSQbwLooXSdLbqPB42KxT6olKYA== =0tVS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 12 15:12:36 2019 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 0F1D9120178 for ; Wed, 12 Jun 2019 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSm_RuFiHj90 for ; Wed, 12 Jun 2019 15:12:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33640120089 for ; Wed, 12 Jun 2019 15:12:32 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 05E21380BE; Wed, 12 Jun 2019 18:11:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0EC2A1301; Wed, 12 Jun 2019 18:12:30 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0D4A391F; Wed, 12 Jun 2019 18:12:30 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: mud@ietf.org In-Reply-To: <901002AC-14C0-41DE-AC96-1A709C9CF15B@cisco.com> References: <2441.1560362719@localhost> <901002AC-14C0-41DE-AC96-1A709C9CF15B@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] content-type for MUD files 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, 12 Jun 2019 22:12:35 -0000 Eliot Lear wrote: >> On 12 Jun 2019, at 20:05, Michael Richardson = wrote: >> >> Signed PGP part >> >> RFC8520 does not as far as I saw, define a Content-Type for MUD file= s. >> I think that this is an additional to-do. > It=E2=80=99s in there. See Section 17.5. Good! I was searching for "Content-Type", which was clearly a mistake, as I should have been thinking Media Type. Duh on me. Media Types go in the Content-Type header. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Wed Jun 12 15:14:46 2019 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 B2979120192 for ; Wed, 12 Jun 2019 15:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viagenie-ca.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz0ZaiDZ2woM for ; Wed, 12 Jun 2019 15:14:40 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 AFE4F120145 for ; Wed, 12 Jun 2019 15:14:40 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id 33so12141959qtr.8 for ; Wed, 12 Jun 2019 15:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nuAR55ImSlcc6eCF4RouIn3C7sAWOJkNHkdv8B6s5fo=; b=C8MWS4gwBRNjEt9vu4Il3EjcCMK1JHxQpWbnK8gaVrh/SsPDTnLOftViflh0Cyg6E6 IKHZkUGFA35tVnXhKv21PJg0uWCvpF3ghC6/rJgQQ/+X2Rtj32O0AJgxgQhqow6pO7TL +aBBno9Zmqvr2xvlQUNetGDdxd9B1Nd0Ex4Ri2EZV8ihB8G1AuA4qZ6fxOecxV985ZSr 7xUmoI4uE/5gV6DuUJqKr0Os26PbaHgya3biCTTJISBKlGLwJPFMO8g+1hYIdF/ZBsw3 e2xTOKJv9AC43U1HkPowF2IWzKeEQhIzX8DGjqzTc/3sfuFRUBTPEovWK3uGZ3VEKr40 G8qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nuAR55ImSlcc6eCF4RouIn3C7sAWOJkNHkdv8B6s5fo=; b=f9ctseZkG6fMAMRJYZSKbaGnhvHKBgZQg7XUdhzYVK5xYbwNehqovkJtnEdevaASvv h0by35KxaURjhNY7HyUopL/GO0PRE8KbSj1x/5CktqebZ+vKDFeTcT+zbfsxBXNM+kH3 Bf1ilgnXNupEzVJv+F3WGxMIoCPp1Vq6rZizHajBIw9Pn9TnL7XhHs6htyD5sjs/LB9l a+6DMtsxx3Yoywbc9B/iOvwd8LBab/7ddrYfNN3PVTZgABvmC0AICeHFC1/KZWU+bFYb 9X41UXzBvuDtJpwPMbBhgqMfhC79pkXfmnnqx0I67MQrQ61V0CvUv9ybl0b1bp7Dgobo 6Y1Q== X-Gm-Message-State: APjAAAXhG+UMUK8ABsKKebXCcu4JoCGZUEl47HIVoUb24kAWS595I81Y JGjf35Fsvh+N7z6GCCFOn50wOA== X-Google-Smtp-Source: APXvYqzgvzs9XezchM4r1odSIZ4CnlOzwr8v8eUewiaPyzJfZKVPcdko7QJdnTcRdvYhz1OSj5GWOQ== X-Received: by 2002:a0c:f9c1:: with SMTP id j1mr667472qvo.235.1560377679938; Wed, 12 Jun 2019 15:14:39 -0700 (PDT) Received: from [206.123.31.156] (modemcable138.218-70-69.static.videotron.ca. [69.70.218.138]) by smtp.gmail.com with ESMTPSA id m5sm585051qke.25.2019.06.12.15.14.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jun 2019 15:14:39 -0700 (PDT) From: "Marc Blanchet" To: "Michael Richardson" Cc: "Eliot Lear" , mud@ietf.org Date: Wed, 12 Jun 2019 18:14:37 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: <01192B95-1F17-4CB2-89F5-7ED2D271F8D6@viagenie.ca> In-Reply-To: <4395.1560377550@localhost> References: <2441.1560362719@localhost> <901002AC-14C0-41DE-AC96-1A709C9CF15B@cisco.com> <4395.1560377550@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Mud] content-type for MUD files 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, 12 Jun 2019 22:14:43 -0000 On 12 Jun 2019, at 18:12, Michael Richardson wrote: > Eliot Lear wrote: > >> On 12 Jun 2019, at 20:05, Michael Richardson > wrote: > >> > >> Signed PGP part > >> > >> RFC8520 does not as far as I saw, define a Content-Type for MUD > files. > >> I think that this is an additional to-do. > > > It’s in there. See Section 17.5. > > Good! > > I was searching for "Content-Type", which was clearly a mistake, as I > should have been thinking Media Type. Duh on me. well, I do that mistake quite often too… Marc. > Media Types go in the > Content-Type header. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud From nobody Thu Jun 13 12:23:25 2019 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 13527120623 for ; Thu, 13 Jun 2019 12:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Ftbk1UkIW68S for ; Thu, 13 Jun 2019 12:23:22 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 CA4D4120620 for ; Thu, 13 Jun 2019 12:23:22 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id e5so451997iok.4 for ; Thu, 13 Jun 2019 12:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ukHUkuMggXpwklJnJ/ingWU1xDTj/xG3h+O7A2I735w=; b=VYu6IM6jL4kNSbNTJpG7SbZ0AfGO+e4gMwnfp3jecgJG7XlFxt216Hq8OIu9n/AHB5 jrksnT9prVAofy5/d90Lafdbrtfti1Ceu/UaNqd4I/zqIHaeCs2b3HMLqsXrHxEESmTn kgmST71QHPsxuFVZyEFPr+HIT1vz6ToUJCnFF95S55LO6OUJeA1vRuq+dsK6vDbSfgqs yCcOajl7qEmvZVUO+A+4kUfwnVliAasUP+O1kV74dKFKn6h6D39dT9hdaRofOEP2L7Xp orX2Gh3Es7AZCsR5pSbGxRsLGCR8qWakhjDeudgCvTX0iuz05iLxwhFgG5vdsoMhyejk wIUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ukHUkuMggXpwklJnJ/ingWU1xDTj/xG3h+O7A2I735w=; b=KUmygEFDIYMaNd2aL3jY8Gzt+gKApAuELkKpU90vuGPObVtYsFyUMBSs1+mdCnEFw8 KPI4hSsx+YQmM5NhVo/FrTRseV9SkrtWxZWr+wZHAZAdZkjqDdBg/QBZLLqYCMo7A/hQ CK2OAjtT4v9AP6F1CySkvBIYdK02098sw77pmcnkLN74F8zUUut5Hkqo44eknQIUY99A a/TQfK6P3O0Ukw7/R4UhiQbQ0A4dDfVi46/PFzfzXULWnuZ7K5IXcjf5elXxqGth1le3 CIHqW5TrP+N1iQsS87pHchGKhMqs2FCpNMEfYfSQamDPhqvIt9b7vr5KH9/HAngsGoqi SeUg== X-Gm-Message-State: APjAAAUGXxHcFBJwY1rnsT+ISH1fVBAEUh8pEhlw7w5r8GqIpAsMf//i QWT3ub+zj4607VlTi9MJ9o6n8rqKGd6fVhi3sb9v3Cbl X-Google-Smtp-Source: APXvYqyCYlH05Uwh4g6WnYN7XBRY/c0jNr+6AcoVMmoA7z3aYxwGkHACag1qU7Q12ImjEUQYdOS9bCIGpvT7iYnM7Nk= X-Received: by 2002:a5d:9448:: with SMTP id x8mr55713195ior.102.1560453801734; Thu, 13 Jun 2019 12:23:21 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Thu, 13 Jun 2019 15:22:45 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a7bab058b3976eb" Archived-At: Subject: [Mud] Disambiguating MUD rules 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, 13 Jun 2019 19:23:25 -0000 --0000000000008a7bab058b3976eb Content-Type: text/plain; charset="UTF-8" If there are two ACE's in a MUD rule, one for say "controller" and another for, "local-networks", how should these be disambiguated? 1. Most permissive rule wins. 2. Least permissive rule wins. 3. A host designated as a "controller" is not part of the "local-network" classification. 4. This is a network admin concern. 5. This is a network configuration error and the MUD server should reject it. If there's some guidance in the mud spec on how to disambiguate such situations? Thanks, Ranga -- M. Ranganathan --0000000000008a7bab058b3976eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If there are two ACE's in a MUD rule, one for say= "controller" and another for, "local-networks", how sh= ould these be disambiguated?

1. Most permissive ru= le wins.
2. Least permissive rule wins.
3. A host desig= nated as a "controller" is not part of the "local-network&qu= ot; classification.
4. This is a network admin concern.
5. This is a network configuration error and the MUD server should re= ject it.

If there's some guidance in the = mud spec on how to disambiguate such situations?

T= hanks,

Ranga

--
=
M. Ranganathan

<= /div>
--0000000000008a7bab058b3976eb-- From nobody Thu Jun 13 13:00:01 2019 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 B43D21206F4 for ; Thu, 13 Jun 2019 12:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 zPuuLw7hwTPv for ; Thu, 13 Jun 2019 12:59:58 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 15A9A1200F6 for ; Thu, 13 Jun 2019 12:59:58 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id h6so706626ioh.3 for ; Thu, 13 Jun 2019 12:59:58 -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; bh=04+P8VrFNxAUnz6WstHWWDEGApmQLNA6Ra3OMaeyYwI=; b=bEtdj+kvUZKXS0lB524++j4YJaX3YDsfvZk+8W4avSMtlMSblRbrX2pVwVoHOCslrd pkjZvHCQWZOqsxj9ZOfWOsXHf+EsMPgbfc5nCwqh29CgBiFDvberQ4QoojMTibGB33Qi UpMC3sKhb+UM76thvdOpBDr7iAOWYcCO/8s0HerJ9ME5VMwM+o/1GuRPqbXSUglzKXJD Ze8Qs51AO4puroQYXLwmk4dDy2MxZcynR0NPCjQ8RqQKMR14tnPkxvT9A27V2+MsLF+W f+ndVM2N1vAdSeLpea8OzAkXNtjdBrG6zW8aA7tEEQJ1C+kmTqzc9ithljoZM5kFz/yW HZhg== 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; bh=04+P8VrFNxAUnz6WstHWWDEGApmQLNA6Ra3OMaeyYwI=; b=R19Kfw2vmqDu9d7cTXCUh/2ajWGjZfkhyli7cqy8K2l/gzG4WyOZQQAAjx6xAysZG8 wJxZ9IMsGcHCipxl8EmkXvAT5gBFLSlpupoC2bySA/1fxzBNfwGixGzyrYsPi6WYDPLX 65cuH9qltaWhPhehu1Qd0GHx8XKcxiGG0WwdXmhjdwJyOp98fw+jCniMg2qsK+e0nHB1 SlHzJx7HbODou47cEkmK8RCfXKvPljF2Ci7Wp/oiEBu4L0jO3v9ZKcNPAwLsXqvzPf+8 tE/+yl9qsDREJYDAU3bJum7RO8fJts0+1hnlQvn5f7Rije05+hApBH8OjxGGC9ko+XYD WTcg== X-Gm-Message-State: APjAAAWfyC6NAUZvCdYPIKvVta18tJ7zIcsm8n+9HAgE0d9rN+9a9G7d XCHYOzS1BPiK5P3j0unXEYMgC0nq5dpnXJWXyD9pIcY/ X-Google-Smtp-Source: APXvYqx9RaPGJwPJSVkmd0wCveKzIlsThfp4SkX5dQYQWKUFupoB0g3ORSr5oRu+G0kK6AOE4TsVrEXrnFilEYUxeFE= X-Received: by 2002:a05:6602:2252:: with SMTP id o18mr5542745ioo.63.1560455996549; Thu, 13 Jun 2019 12:59:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "M. Ranganathan" Date: Thu, 13 Jun 2019 15:59:19 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000005cad73058b39f9b5" Archived-At: Subject: Re: [Mud] Disambiguating MUD rules 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, 13 Jun 2019 20:00:00 -0000 --0000000000005cad73058b39f9b5 Content-Type: text/plain; charset="UTF-8" Forgot to add one thing: In this case, the controller host is also on the "local network" (e.g. on the same subnet ). Thanks On Thu, Jun 13, 2019 at 3:22 PM M. Ranganathan wrote: > If there are two ACE's in a MUD rule, one for say "controller" and another > for, "local-networks", how should these be disambiguated? > > 1. Most permissive rule wins. > 2. Least permissive rule wins. > 3. A host designated as a "controller" is not part of the "local-network" > classification. > 4. This is a network admin concern. > 5. This is a network configuration error and the MUD server should reject > it. > > If there's some guidance in the mud spec on how to disambiguate such > situations? > > Thanks, > > Ranga > > -- > M. Ranganathan > > -- M. Ranganathan --0000000000005cad73058b39f9b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgot to add one thing:

In = this case, the controller host is also on the "local network" (e.= g. on the same subnet ).

Thanks
On Thu, J= un 13, 2019 at 3:22 PM M. Ranganathan <mranga@gmail.com> wrote:
If there are two ACE's in a MU= D rule, one for say "controller" and another for, "local-net= works", how should these be disambiguated?

1.= Most permissive rule wins.
2. Least permissive rule wins.
<= div>3. A host designated as a "controller" is not part of the &qu= ot;local-network" classification.
4. This is a network = admin concern.
5. This is a network configuration error and the M= UD server should reject it.

If there's so= me guidance in the mud spec on how to disambiguate such situations?

Thanks,

Ranga
--
M. Ranganathan

<= /div>


--
M. Ranganathan

<= /div>
--0000000000005cad73058b39f9b5-- From nobody Thu Jun 13 13:03:01 2019 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 0E3F71206FC for ; Thu, 13 Jun 2019 13:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 SlJ-4biPhpFr for ; Thu, 13 Jun 2019 13:02:57 -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 83AE61206F8 for ; Thu, 13 Jun 2019 13:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1652; q=dns/txt; s=iport; t=1560456176; x=1561665776; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ZzwR1GAHwkAsYcOxUQGid6vijbrBdeazNy7p7bUVdLk=; b=lEcIr4acZHYvZ5hXkS73ouLi0a+0EuCIcdDm7ajyEseFXQPxyMdgWrnV UA2vPUO63yhxxc8HF8q5TSakwtM3fE8sayS4RGjTj0iAjAnlpqrxYI4qp VFIzgA+6kJrGHcrbGTPe5sG4q4yKkcrrUAgvdUGCZ4SXd1NTlptem66wH w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAADIqgJd/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCEGpRASASKIQWiHuMCIlDkRkCBwEBAQkDAQE?= =?us-ascii?q?YCwwBAYRAAoJsNwYOAQMBAQQBAQIBBG0cDIVKAQEBAQIBAQEhSwsFCwsYKgI?= =?us-ascii?q?CIQYwBhODIgGBagMODw+rSIExhUeCOA2CEwoGgTQBgU+KJIF/gTgfgkw+ghp?= =?us-ascii?q?HAQGBS4MgMoImBJQelHA+CYISghuBBoxAg2sblyyWHIpJgwgCBAYFAhWBZSK?= =?us-ascii?q?BWDMaCBsVOyoBgkE+ilWFQT0DMJE1AQE?= X-IronPort-AV: E=Sophos;i="5.63,370,1557187200"; d="asc'?scan'208";a="13072070" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jun 2019 20:02:53 +0000 Received: from dhcp-10-61-101-199.cisco.com (dhcp-10-61-101-199.cisco.com [10.61.101.199]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5DK2qLg028991 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Jun 2019 20:02:53 GMT From: Eliot Lear Message-Id: <28125A5A-8F61-48CD-96E6-7A184802B102@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A05FE98B-3CC5-42DF-8681-7CD4244C1715"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 13 Jun 2019 22:02:51 +0200 In-Reply-To: Cc: mud@ietf.org To: "M. Ranganathan" References: X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.101.199, dhcp-10-61-101-199.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Mud] Disambiguating MUD rules 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, 13 Jun 2019 20:02:59 -0000 --Apple-Mail=_A05FE98B-3CC5-42DF-8681-7CD4244C1715 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Jun 2019, at 21:22, M. Ranganathan wrote: >=20 > If there are two ACE's in a MUD rule, one for say "controller" and = another for, "local-networks", how should these be disambiguated? In the same ACE? It shouldn=E2=80=99t happen. The spec doesn=E2=80=99t = explicitly say so, however. I view that as an erratum. A way of = looking at this is that there should be at most one host abstraction. Eliot >=20 > 1. Most permissive rule wins. > 2. Least permissive rule wins. > 3. A host designated as a "controller" is not part of the = "local-network" classification. > 4. This is a network admin concern. > 5. This is a network configuration error and the MUD server should = reject it. >=20 > If there's some guidance in the mud spec on how to disambiguate such = situations? >=20 > Thanks, >=20 > Ranga >=20 > -- > M. Ranganathan >=20 > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud --Apple-Mail=_A05FE98B-3CC5-42DF-8681-7CD4244C1715 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQKr6wAKCRBugA9nE248 uDwHAJ41ImZzFt/BKKZUvYH0jC0pdRfF3ACgqaLBUj25KHExJx367vSZVe67Rd0= =K9BU -----END PGP SIGNATURE----- --Apple-Mail=_A05FE98B-3CC5-42DF-8681-7CD4244C1715-- From nobody Wed Jun 19 10:05:51 2019 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 55BEF1205D8 for ; Wed, 19 Jun 2019 10:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 2o9Co9Xf5xRt for ; Wed, 19 Jun 2019 10:05:47 -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 087341205D6 for ; Wed, 19 Jun 2019 10:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=900; q=dns/txt; s=iport; t=1560963947; x=1562173547; h=from:mime-version:subject:message-id:date:to; bh=EW0PBU5Mxxo/3x5C6kcMbTCli6iaAGLIS79iKmPI4/U=; b=AkdUkZWk5VvLg0DdRqPOPnEVrFSfDYfkhfo6nHb03AQoL00hpljJfwVK pxele08G4Pk8H/Af5MscPndBFGeRk5+RqlAo89lE42ngHnK4lM8IixIRu rT8zsZV9f54WRWVSLrQ9xy48wxaxV6uVJtehkhNGtlAAUYpWD/XPMg1ZJ M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAAAUawpd/xbLJq1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBghZHI1EBIBKNOYtgmQmBewIHAQEBCQMBAR8QAQGEOIMFNgc?= =?us-ascii?q?OAQMBAQQBAQIBBW2KNwyFaYVUAYIKD50GkCyEMgGFcgoGgTQBgVCKJIF/gTg?= =?us-ascii?q?ME4gbgm+CJgSULYdQjWgJghMDghiBB5AxG4IXAZUcoHyDCAIEBgUCFYFXCCm?= =?us-ascii?q?BWDMaCBsVZQGCQj2Fc4pVPQOQIgEB?= X-IronPort-AV: E=Sophos;i="5.63,392,1557187200"; d="asc'?scan'208";a="13290371" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jun 2019 17:05:43 +0000 Received: from dhcp-10-61-102-117.cisco.com (dhcp-10-61-102-117.cisco.com [10.61.102.117]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5JH5g2A016821 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 19 Jun 2019 17:05:43 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_9BD5C49C-50BE-434A-B7ED-B496DE4334D6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <365CA02E-6400-4E23-A12C-B730892D6306@cisco.com> Date: Wed, 19 Jun 2019 19:05:41 +0200 To: mud@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.102.117, dhcp-10-61-102-117.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Mud] Hackathon ideas for MUD 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, 19 Jun 2019 17:05:49 -0000 --Apple-Mail=_9BD5C49C-50BE-434A-B7ED-B496DE4334D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, A reminder: we are looking for additional proposed areas of = collaboration for the Hackathon. What would you like to code up/test? https://www.surveymonkey.com/r/9WTR8HC Survey will close on Monday. Eliit --Apple-Mail=_9BD5C49C-50BE-434A-B7ED-B496DE4334D6 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQprZQAKCRBugA9nE248 uGxNAKCevUfTpIyd1fIoCNJ1zz4zWLibeQCgpl0h17apy5OPYLUjyW3M4HZZs8E= =+hzr -----END PGP SIGNATURE----- --Apple-Mail=_9BD5C49C-50BE-434A-B7ED-B496DE4334D6-- From nobody Wed Jun 19 10:42:11 2019 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 C2712120390; Wed, 19 Jun 2019 10:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 cNdbSiRUfw7X; Wed, 19 Jun 2019 10:41:55 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9E91203DE; Wed, 19 Jun 2019 10:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1021; q=dns/txt; s=iport; t=1560966094; x=1562175694; h=from:mime-version:subject:message-id:date:cc:to; bh=nJfcfU78WGhAlhy9T6sChA2U2gsBhpq+R9ncwTA+2r4=; b=SsroC1rd8Ao3f2pD7MLhC835yuHZBSoW4ilXVgPDY9MXXVBglo0/ngLZ l5loRt9xI4NCd6p6s2NCpdP7P6d8Lpvsq581Xb1HIhXpDFvLXXqcu/KS5 rZx5A/GbM5gNZS20QgCmrPi6UA7FEtGiqdXSh3ncT2z2abRl+pfTl29w5 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAADXcgpd/xbLJq1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBghaBOwEgEoQ+iHuLYJkJgXsCBwEBAQkDAQEvAQGEQIJ9Ngc?= =?us-ascii?q?OAQMBAQQBAQIBBW2KQ4V0Vl0ChBQBggqsKoExiiYQgTQBgVCKJIF/gTgME4g?= =?us-ascii?q?bgj0ygiYElC2HUI1oCYITghuBB5AxG4IXAQ+HBo4HoHyDCAIEBgUCFYFXAy6?= =?us-ascii?q?BWDMaCBsVZQGCQj2QSD0DkAUBAQ?= X-IronPort-AV: E=Sophos;i="5.63,393,1557187200"; d="asc'?scan'208";a="13351074" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jun 2019 17:41:31 +0000 Received: from dhcp-10-61-102-117.cisco.com (dhcp-10-61-102-117.cisco.com [10.61.102.117]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5JHfSF4027501 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Jun 2019 17:41:30 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_5AC08B40-EAED-4539-AD1A-D3CE74309B3F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 19 Jun 2019 19:41:27 +0200 Cc: mud@ietf.org, iot-onboarding@ietf.org To: iot-dir@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.102.117, dhcp-10-61-102-117.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Mud] Hacking MUD at the Hackathon 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, 19 Jun 2019 17:41:57 -0000 --Apple-Mail=_5AC08B40-EAED-4539-AD1A-D3CE74309B3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the blast here, but=E2=80=A6 Attention: IoT device folk. Would you like to try testing your device = against MUD network protection? We=E2=80=99re going to bring some h/w = and s/w to the Hackathon so that you can see how the protection actually = can be invoked by your device. Interested? Unicast back please. Thanks! Eliot --Apple-Mail=_5AC08B40-EAED-4539-AD1A-D3CE74309B3F 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQpzxwAKCRBugA9nE248 uOO5AKDGwOLj0MShTeYNFPy1TpoLmp1OMACg/4UlQ6/SA7CXbp6xmg+FN69L4CU= =yS1+ -----END PGP SIGNATURE----- --Apple-Mail=_5AC08B40-EAED-4539-AD1A-D3CE74309B3F-- From nobody Wed Jun 19 11:25:30 2019 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 B2B8A12071E for ; Wed, 19 Jun 2019 11:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8MLmdOuQxrdm for ; Wed, 19 Jun 2019 11:25:27 -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 4CA311207C3 for ; Wed, 19 Jun 2019 11:25:27 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id r185so747232iod.6 for ; Wed, 19 Jun 2019 11:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zhD3uBN74DtTzB2+jmwG5W/R9/WV+6z4++MvFsFDgNY=; b=bsBob0JFKon7SERDL3PTyBtV8s/XLVNNRFekPWP3bNtIq32WMZeXgVAyPbctPli6b0 DdKlcAHUImsoMck7ACox2xFALQc81qgZDamfSDbxwQPl6WQWzWlvXWv/BJlc/xk8UBOt DalLKmFAbbEdCtN1ZfmrG28kTUmSgTfCCqHjpcPNmne9r73AFWpkUdzAngnCISh3YuYH y2qneYJKIq0Ab40Pwykyh2U9eWija6tGKmgmu0vUkV1qL+mzFf7szZl0wUpm/k1BocG8 rfe3wR1QkZnv78wFURC55Fr0Cr8qTWBPn0tIaz5UUKAhc6YZb5DGT2Kr8BLvfrjqWa93 jsTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zhD3uBN74DtTzB2+jmwG5W/R9/WV+6z4++MvFsFDgNY=; b=gpbkoesrB13SPD9zMU+c8AYWmqkk1xJS+zxnFll3weWLz0nfncHYQOLwHvq/xXCdLA ql8f4slVDK/V14Feg/pFfCG7AaarjZyuvn695vYUwuyzGX9PVz6TD/xS//Qo+6E4xXak FfL8F7K4RdE/oBUbGyWeZ0ACumaUbaPn3FCMXbvOkxmYyaS0Yfsv7okyeBof2+sIhUa6 SVeD6GUocyOSW6iwlig33z0VKk8zNKH95uFlwuu1+AKdCnQ4RX+0RUJJvk3T1ckuHLcH aTBXq6ySYJGvm+JWhNMF11bK5fR5cnsU6l+QZHnZClXQJGPFeJT4VCGhqdeELZl5EZql cIow== X-Gm-Message-State: APjAAAVpG8vcdt2Mz4REhacrU3IGSYzX3I/LtcPczg8dkaLn6gcB7b19 d1G8RZDctrR6UscCBEsITF5MqbC9Funiw3QwfcHBPBvM X-Google-Smtp-Source: APXvYqyqj+obs1vFARCu+u/NrFEbJADj3TcJ30i/Will9hTMbQ6zS7E6kf/95fImsiOH3gy8K2xhXpYxmgWKrVb6O0U= X-Received: by 2002:a02:3308:: with SMTP id c8mr29544234jae.103.1560968726015; Wed, 19 Jun 2019 11:25:26 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Wed, 19 Jun 2019 14:24:49 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000006b7303058bb15a51" Archived-At: Subject: [Mud] More disambituating MUD 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, 19 Jun 2019 18:25:29 -0000 --0000000000006b7303058bb15a51 Content-Type: text/plain; charset="UTF-8" I have two devices - one by manufacturer A and another by B Mudfile for A says I can talk to devices made by B on port 80 TCP. Mudfile for B says I can talk to devices made by A on any protocol / port. It is reasonable to assume that most restrictive rules should apply (i.e. A and B can only interact using TCP port 80). Just checking assumptions.... Ranga -- M. Ranganathan --0000000000006b7303058bb15a51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have two devices - one by manufacturer A and anothe= r by B

Mudfile for A says I can talk to devices ma= de by B on port 80 TCP.

Mudfile for B says I can t= alk to devices made by A on any protocol / port.

<= div>It is reasonable to assume that most restrictive rules=C2=A0 should app= ly (i.e. A and B can only interact using TCP port 80). Just checking assump= tions....

Ranga

--
M. Ranganathan

--0000000000006b7303058bb15a51-- From nobody Wed Jun 19 13:32:05 2019 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 A0C7A1201F8 for ; Wed, 19 Jun 2019 13:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 36qimc16cjRd for ; Wed, 19 Jun 2019 13:32:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1DC12015A for ; Wed, 19 Jun 2019 13:32:01 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 28AA538185; Wed, 19 Jun 2019 16:30:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F3440E9E; Wed, 19 Jun 2019 16:31:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F0EA0E97; Wed, 19 Jun 2019 16:31:59 -0400 (EDT) From: Michael Richardson To: "M. Ranganathan" cc: mud@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] More disambituating MUD 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, 19 Jun 2019 20:32:04 -0000 --=-=-= Content-Type: text/plain M. Ranganathan wrote: > I have two devices - one by manufacturer A and another by B > Mudfile for A says I can talk to devices made by B on port 80 TCP. > Mudfile for B says I can talk to devices made by A on any protocol / > port. I think that we all assume is that all rules are "stateful", or apply to TCP SYN packets only. Otherwise, A can't get packets back from B. Maybe RFC8520 spells this out somewhere, I can't recall :-) > It is reasonable to assume that most restrictive rules should apply > (i.e. A and B can only interact using TCP port 80). Just checking > assumptions.... The ACL has a default block at the bottom. That means that the set of rules above that block should be an OR'ed together. If we go with that, then it would not be most restrictive, but rather least restrictive, but that means that B's mudfile can open up A for attack. So, B *is* allowed to talk to any device on any port. If it does so, it is not in violation of it's MUD file. So no alert. Device A, however, did not allow *incoming* connections in it's MUD file according to the rule you posted. So, when B tries to talk to it, the packets are dropped, just as if some script kiddie on the Internet was trying to connect. Device A is not violating it's MUD. So, also no alert. Where should a record of these denies go? I'm not sure. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0Km78ACgkQgItw+93Q 3WXdrgf/cjSlnw5z+nO3Qj0Xgj45Dcmqqe/K0UCLsm/vaKPr3ZRRrc376Rzc1Cr4 kAcnWAh/WiTyU1fIjCd6UBuWotcGWYhuAZte9yZITfdIbrC6HqHMXlZLJYIggmlE bhmL/YyhPv/O+3Sm9HQ7UQP7qbxgmvrFs60Gy47Cf23g09xpEVfKLJ5+zrvrhUw5 u24j8Gax8VzFHRl2wpKYuRaarytz589bEHQSygJbHLeyWNPYXpuFPeAMY/hQq3ZQ nDvrW4hJeA+wyEqgDBMoiVN74iYfG4ndSMiYtSnaNQM3NfuZR2AdZVjxGljxZYM+ GA1Tyz4c3LVhF8D1MmJLZWiyZ7IX8Q== =dT7A -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 20 07:21:51 2019 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 A531B12008B for ; Thu, 20 Jun 2019 07:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 vknd3W4gZC4Z for ; Thu, 20 Jun 2019 07:21:44 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 677DB120089 for ; Thu, 20 Jun 2019 07:21:44 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id e5so20905iok.4 for ; Thu, 20 Jun 2019 07:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=foxX61K9SZRRUYvsGJL2YHIH7FJeXKqHtfBZu7bClFs=; b=aD/+FSi87/vjmHfI9X2PqRUlIwVEQxXF9kyxgesLKst6DhxQ1zOyJ0yW3RLge0sLrq LdXgS43UE4kUU7KXMB7RBcAQU2q73FYvRH06nfsnyuj1bIooEgjtzHB8ez5kVzftlj9o mxW0GF0BiFyXvdnGN/5A5YhB5n9caPNX5NyA6BBzlD6+i9yXizW3yxMoObkmUS+YD/PY 39I51XtX5FuFedyqSkuXzOUKmGBIrwVUBBL0wUjb21pe4iBYnUqgst0f9ZbGtEFpJdRj o3TU5qQBAoaEWQQroiWa5usTfWPY/Rdk23sQEneYaOh9rLlMU9IYClL99TXzLAktXYQw qVFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=foxX61K9SZRRUYvsGJL2YHIH7FJeXKqHtfBZu7bClFs=; b=UsC9bTzvMLSyN4KscRpeelmd4yCu1A6rmYfZNL5EsVz3Pjc3GnoSI2XS/lA91ADFqB EQx9m4+DBHZ0+o4a1hnVmKAN8JrdPGbOvynWphVg1MYwCyBQ3/MmZ30CP7SEc7sDAIpC SrGgrkSLMakT3kRWHtlvUtZwhaZFeqAZb55MPjs2H3Wko3cKPqy4nHyzsMUaYiaWok+9 ZXbBaMNI8YEoqRy22YK3rUIAyoopkVHPvSZZ+9/LxNithZ7TvbN+J0CL+ehMeFjQ5rmu e2JrwBKC2C9apc2HIjzVzn/8Ehk6EtjZGRNDwm067U6uxjctD1OLgiHybQH3KCAlStnN 9JEQ== X-Gm-Message-State: APjAAAVJ1qjVnZKjtkoc0z31o4kjr1QWZ9zZ+vbgLQGtkFIzfGAOWB2g YSsuISdrQEufiw3fEdM6BD+gEtkoJjoh6mI72ilDS1yE X-Google-Smtp-Source: APXvYqw+nFwGvk0eEMh/R+t4LFaYFZYxVYH9sp/te4W9opivzy63OFdoEgnveR40r3jq6X8+mKwaccc1FvhyPDEIN9o= X-Received: by 2002:a5d:8c87:: with SMTP id g7mr19961416ion.85.1561040503233; Thu, 20 Jun 2019 07:21:43 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Thu, 20 Jun 2019 10:21:07 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000acdf7d058bc21049" Archived-At: Subject: [Mud] How does MUD deal with broadcast IP addresses 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, 20 Jun 2019 14:21:49 -0000 --000000000000acdf7d058bc21049 Content-Type: text/plain; charset="UTF-8" Various protocols (e.g. mdns) could use LAN broadcast addresses. How do we deal with these in a MUD file? e.g. MDNS uses 224.0.0.251. Should this be a controller class? Thanks, Ranga -- M. Ranganathan --000000000000acdf7d058bc21049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Various protocols (e.g. mdns) could use LAN broadcast= addresses. How do we deal with these in a MUD file?
e.g. MDNS us= es 224.0.0.251. Should this be a controller class?

Thanks,

Ranga

<= div>
--
M. Ranganathan <= br>
--000000000000acdf7d058bc21049-- From nobody Thu Jun 20 07:23:37 2019 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 DE1FE120089 for ; Thu, 20 Jun 2019 07:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 79c1NlojuL-l for ; Thu, 20 Jun 2019 07:23: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 4114512004A for ; Thu, 20 Jun 2019 07:23:32 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id u19so1203818ior.9 for ; Thu, 20 Jun 2019 07:23: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; bh=3jZMTwCpeydvfQAB4paMMUNjRlT5AXaxKM2MLTCMcWQ=; b=WzSuXCak039LkRlSETsv63kkAu9SjQ9ucfdt4EClM4c478wBMbBUG3f1TUhj8iysIE wn48lbR0stLoeGWbWL/lZbAQlGmULRfdJdeBpgtUglXJPGYJ78kXCoUvHo2GzoswY574 PV299UOAH3gOZhhA+z7TxyV1OfgE8wOuLoFtyOkUkSdBeWGMzM7r+BU46EommiiKU8bQ f4DIoYkIPEYrLY1hHMQ7nwLxZUSo7eL2ByUduz1aB2gFkB0cPvfYelIxx3+SwtS+nQrB IahgsL5xfiBQhRm562TrB72t2Chu6PK+AEbAnfHuqFLvN4crLsA+ldgU+xIMatDB0daa 1jBQ== 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; bh=3jZMTwCpeydvfQAB4paMMUNjRlT5AXaxKM2MLTCMcWQ=; b=Zx8XrffvAKpxkKO2F2J8Xbcbq2rQNn+L9H2D44Q/tTIFIQdGfJ87ItRXzj3Da8Qmau sSLwaxWUpzqHF25hfH1f1PsjVHqan39WpbJrW6mPAmSAu4s5esHdSI+rtzMvxpd0HIhp 7tAxki858BbEEwiAhm8FxTkjgoud5CRKrxLw9YP5WtsZLcmOa+sz3SrBHOqG719BCxTF blWcxupr9vVq2UNonTsHf0wbHN5u3lnHJN2TOlE7c5Fqs7xnqPcS+msHgDaECfPrN1iQ qsbSu6sakTUG+giDp+/bUhaogM2t3Pnv66IBKHoPMlo4TzMzllNJ1Ei02arWBcAnMUDX 5Zow== X-Gm-Message-State: APjAAAXVJ3R/p8r3HMMeMjq8sqGvgvujvwgQmntrxxbcaomj2QqzTkLy U+CbrAg/PuH0YPQackV978yCtejTn/LdFkGbp77vHNTe X-Google-Smtp-Source: APXvYqyDp31KknqIfU/5c7LkRUUl4JHPSZjSAGz4gJrRhfsrjy7lPKlGkdYgGEc01VRWkKBxp2Cr+kHoV3izpOHuXFQ= X-Received: by 2002:a02:6a19:: with SMTP id l25mr99890038jac.123.1561040611029; Thu, 20 Jun 2019 07:23:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "M. Ranganathan" Date: Thu, 20 Jun 2019 10:22:54 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000019b744058bc217a6" Archived-At: Subject: Re: [Mud] How does MUD deal with broadcast IP addresses 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, 20 Jun 2019 14:23:34 -0000 --00000000000019b744058bc217a6 Content-Type: text/plain; charset="UTF-8" Correction - I meant multicast (not LAN broadcast). Thanks. On Thu, Jun 20, 2019 at 10:21 AM M. Ranganathan wrote: > Various protocols (e.g. mdns) could use LAN broadcast addresses. How do we > deal with these in a MUD file? > e.g. MDNS uses 224.0.0.251. Should this be a controller class? > > Thanks, > > Ranga > > > -- > M. Ranganathan > > -- M. Ranganathan --00000000000019b744058bc217a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Correction - I meant multicast (not LAN broadcast= ). Thanks.

On Thu, Jun 20, 2019 at 10:21 AM M. Ranganathan= <mranga@gmail.com> wrote:
Various protocols (e.g. mdns)= could use LAN broadcast addresses. How do we deal with these in a MUD file= ?
e.g. MDNS uses 224.0.0.251. Should this be a controller class?<= /div>

Thanks,

Ranga
<= br clear=3D"all">

--
M. Ranganathan



--
M. Ranganathan

<= /div>
--00000000000019b744058bc217a6-- From nobody Thu Jun 20 09:09:25 2019 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 48EDD12011F for ; Thu, 20 Jun 2019 09:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 1qoNkU2pzwV7 for ; Thu, 20 Jun 2019 09:09:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4611200FB for ; Thu, 20 Jun 2019 09:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1267; q=dns/txt; s=iport; t=1561046962; x=1562256562; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Wr+cVykntYBW9SRsZbTGFWlkJQM9i/9M10eo0Uc84i8=; b=Gm75UoW+IjlPiH0KujqSZcLoO0//NghoW27BNyU4mEquBD7/IjGuxmbA Q541Z27xClQVL/Jhr8Wja5hNZqX4r+q1nYYUKrUVs0xkxaIWgOzjq1/af +kkhMgGa02iQ8EbIAYaJ9AdM6X6Lwq67B6jh5VN50fBj1zozSfCTGc72N c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAfrwtd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBghZHI1EBIBIojDJfjAmJRY8ggXsCBwE?= =?us-ascii?q?BAQkDAQEYCwwBAYRAAoMBNAkOAQMBAQQBAQIBBW2KNwyFSgEBAQMBAQFsCwU?= =?us-ascii?q?LCxguIQYwBhODIgGBagMODw+oZIVHgjsNghUKBoE0AYFQiiSBf4ERJx+CHi4?= =?us-ascii?q?+ghpHAQGFHYImBJQzlH4+CYITghyBCIxJg20bghiVJReWHIpXgwgCBAYFAhW?= =?us-ascii?q?BUDiBWDMaCBsVOyoBgkE+iweFQT0DMI91AQE?= X-IronPort-AV: E=Sophos;i="5.63,397,1557187200"; d="asc'?scan'208";a="13390285" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 16:09:19 +0000 Received: from dhcp-10-61-102-117.cisco.com (dhcp-10-61-102-117.cisco.com [10.61.102.117]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5KG9Irh005767 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Jun 2019 16:09:19 GMT From: Eliot Lear Message-Id: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_EFF2B710-ED13-4DAC-A856-DB1002B604A2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 20 Jun 2019 18:09:17 +0200 In-Reply-To: Cc: mud@ietf.org To: "M. Ranganathan" References: X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.102.117, dhcp-10-61-102-117.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] How does MUD deal with broadcast IP addresses 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, 20 Jun 2019 16:09:24 -0000 --Apple-Mail=_EFF2B710-ED13-4DAC-A856-DB1002B604A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I like the idea of using a class for MDNS. I also think broadcast and = multicast are a bit of a special case, relying on the underlying ACL = model. What do other people think? > On 20 Jun 2019, at 16:21, M. Ranganathan wrote: >=20 > Various protocols (e.g. mdns) could use LAN broadcast addresses. How = do we deal with these in a MUD file? > e.g. MDNS uses 224.0.0.251. Should this be a controller class? >=20 > Thanks, >=20 > Ranga >=20 >=20 > -- > M. Ranganathan >=20 > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud --Apple-Mail=_EFF2B710-ED13-4DAC-A856-DB1002B604A2 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQuvrQAKCRBugA9nE248 uDtvAJ9MddtFErsxTGDnj1LskU82JDW6AQCeJJv8jN5HJDCUXkVzSJBFVQaLZ0g= =+Htd -----END PGP SIGNATURE----- --Apple-Mail=_EFF2B710-ED13-4DAC-A856-DB1002B604A2-- From nobody Thu Jun 20 12:28:42 2019 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 796391200D8 for ; Thu, 20 Jun 2019 12:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vb1ChUN5FYg for ; Thu, 20 Jun 2019 12:28:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD7E12013A for ; Thu, 20 Jun 2019 12:28:39 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 593B638185; Thu, 20 Jun 2019 15:27:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 82CE512EB; Thu, 20 Jun 2019 15:28:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8025BE21; Thu, 20 Jun 2019 15:28:37 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: "M. Ranganathan" , mud@ietf.org In-Reply-To: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> References: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] How does MUD deal with broadcast IP addresses 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, 20 Jun 2019 19:28:41 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: > I like the idea of using a class for MDNS. I also think broadcast and > multicast are a bit of a special case, relying on the underlying ACL > model. What do other people think? So a MUD file for a device that should be allowed to use mDNS would create an ACL to 224.0.0.251? I think that internal ACLs will be very inconsistently applied by mud-controllers. While some will be able to hairpin all the traffic, other environments will make this hard, or will be too costly if there is a lot of traffic. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0L3mUACgkQgItw+93Q 3WXKvwf/czFU3KkCsvJp4DK6iJ4IePtE1VQK/uzHbU7ojHyfkBnBEaTjxULHpYxP tBOpFwHeVUbxiy8NRMw1i/gIlS+vkVvXvtJwJBtjWZNUoIW9ALX6y0eCWqxrnIyh LrTzwxbYcWNylI4AWPZZPle5HRzcLkUYwmtFZjXBnujtY8iBmSHR00JsbphEiaaN sgljW2g5H2zGky6ivBPP2BbddYcniFpzzKncAjfkFOfwyHwtgPqSFrknxOvgTrq3 oJEBXVKNCRNmBGPb6MwS0rl+5zzKDTY3YCZL+80XIz1/m/dS/c81mPO/AD3FYjmA itcXIUm3JFstaee70u5YqaGQNjGjgA== =nTyk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 20 14:36:11 2019 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 D054712015C for ; Thu, 20 Jun 2019 14:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 mmZnAUbHlyZa for ; Thu, 20 Jun 2019 14:36:09 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BEA12006F for ; Thu, 20 Jun 2019 14:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1893; q=dns/txt; s=iport; t=1561066569; x=1562276169; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=0VGvpWOIvK2jEQuF48YPMDns9JBmfDzaelsqM4l0LhY=; b=b1hdFG2mRQO3HpN+HH9ju7eQKAJOw/LAaw8fSccBI4wOr8C2iqcWdi0X vc8+d/jn2ZDnVzAWY6OZQe6EDW5REUkugdNukPcAX1gb+q4d5ddhYTaYO X40e8sBniONgFMp0cutgn8FW2Y/bO+j2esf1f47Q+E67T7u+6XSmxcBsi E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAACD+wtd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBg1IgEiiEFoh7jAqaYAIHAQEBCQMBAS8?= =?us-ascii?q?BAYFLgnUCgwE3Bg4BAwEBBAEBAgEFbYpDhUoBAQEBAgEjVgULCxgqAgJXBhO?= =?us-ascii?q?DIgGBew+oO4Exgk+CeIRgEIE0AYFQiiSBf4ERJx+CHi4+h04ygiYElDOVPAm?= =?us-ascii?q?CE4IcgQiQNhuXPRegc4MIAgQGBQIVgWYigVgzGggbFTsqAYJBPpBIPQMwkBM?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.63,398,1557187200"; d="asc'?scan'208";a="13397755" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 21:36:06 +0000 Received: from ams3-vpn-dhcp5982.cisco.com (ams3-vpn-dhcp5982.cisco.com [10.61.87.93]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5KLa5rT016349 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Jun 2019 21:36:06 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_364D3844-1E7C-4EA3-9426-8299BA4AFB66"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 20 Jun 2019 23:36:04 +0200 In-Reply-To: <30785.1561058917@localhost> Cc: mud@ietf.org, "M. Ranganathan" To: Michael Richardson References: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> <30785.1561058917@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.87.93, ams3-vpn-dhcp5982.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Mud] How does MUD deal with broadcast IP addresses 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, 20 Jun 2019 21:36:11 -0000 --Apple-Mail=_364D3844-1E7C-4EA3-9426-8299BA4AFB66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It depends on to-device/from-device. If the device is including a = from-device and it uses multicast it should probably list it, lest an = inbound ACL simply block the traffic. For to-device, it=E2=80=99s = unnecessary because there are no source multicast addresses. Another = way to address this in implementations is to simply permit outbound = multicast in all cases. > On 20 Jun 2019, at 21:28, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Eliot Lear wrote: >> I like the idea of using a class for MDNS. I also think broadcast = and >> multicast are a bit of a special case, relying on the underlying ACL >> model. What do other people think? >=20 > So a MUD file for a device that should be allowed to use mDNS > would create an ACL to 224.0.0.251? >=20 > I think that internal ACLs will be very inconsistently applied by > mud-controllers. While some will be able to hairpin all the traffic, > other environments will make this hard, or will be too costly if there > is a lot of traffic. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_364D3844-1E7C-4EA3-9426-8299BA4AFB66 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQv8RAAKCRBugA9nE248 uN0nAJ4nNQUkbXkVTxO80qM7OieuWeDkMACfWZ2yipct0C9kVLM19NX2vsL/Sxs= =Mdcv -----END PGP SIGNATURE----- --Apple-Mail=_364D3844-1E7C-4EA3-9426-8299BA4AFB66-- From nobody Thu Jun 20 15:05:47 2019 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 3CEEF120228 for ; Thu, 20 Jun 2019 15:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 KRNFrX8HjGIR for ; Thu, 20 Jun 2019 15:05:44 -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 BA290120224 for ; Thu, 20 Jun 2019 15:05:44 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id e3so887670ioc.12 for ; Thu, 20 Jun 2019 15:05:44 -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=RzFMT9SAUeCCNJ8sBQ5qDPN2hnqnt3B7JzZ1K6N5QdE=; b=C544PvfsOL5PynUkSyITH0r2B4zny8SKanvqGomMi4PAqtNP7woCZ5tFktNjljR2Vf XDOiUOP3EGGIP4+1mMLCl9wp7FPdpybQcKS8HyWSe45uT19ix2TTOHVi3FDlWu9k2jHc MHSTBvg8WQLEPaGvYeM4ffXX41a5RlrS6i2OC9uHr1fkBIFd5Jh+wNzvWmVw+rCgUnsj M3EaPaa/Tc94HW3uDWJSRExb22VKJs1c0oEFMDruUiHWvtQFn70bYWuPOjBbchPwJQhP mbIiWGmAaGLMa7R6LMdFwxlT5zjRVC71W9nu/B0qbbQuLvxbTg2D0f98htiil2ul2lOZ weCA== 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=RzFMT9SAUeCCNJ8sBQ5qDPN2hnqnt3B7JzZ1K6N5QdE=; b=SLtq6TQJjIrOYB0T6NgrxAxEjx8Tl51EZ1A1cg04x1BG0njosP8rlc9jsoYPe5nLdO qKd6eFEjhdQrlMB0rFS72yY8PTqY0miYH0kYrqilRjdHOjIVBQwlIDYLidpMraU3cuth MOYEc5bXEaob6KQ390TV1oLyVN0ng8ejKTvAw261hABWwlz4G4ahVfYhMW/UPw0nmmuK bG5vmvdIH/Liwi3LwxzmtseCSacpkVdRKyE8IGl1Mkxz4dw+lYuHcS4qtAAXM5yUARTt AXhX7TS+ZGiNSDd3Yn/XGDnTdT84eP0yCLBGIBKyjhV3Tx+3zLf7SjuLuoAGFF+G75ub EGlw== X-Gm-Message-State: APjAAAWHNjvwEZlBYEtPfvZ3B177LoXEEkqdrMq9z9X8X9XaE2TGMSgq LSY4frpTfRx5bjf4SlNa+x9fmA1Ah2LE9CaxKK0= X-Google-Smtp-Source: APXvYqyKRltJ9oPtptUjHLczsFbjq4RPOsZ8LSRDhnqtoAYeBJJ1k9nbW3h84Fv8okZWVwTUMzkYITH/FkM1JTaRmDk= X-Received: by 2002:a05:6638:5:: with SMTP id z5mr10648465jao.58.1561068343657; Thu, 20 Jun 2019 15:05:43 -0700 (PDT) MIME-Version: 1.0 References: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> <30785.1561058917@localhost> In-Reply-To: From: "M. Ranganathan" Date: Thu, 20 Jun 2019 18:05:07 -0400 Message-ID: To: Eliot Lear Cc: Michael Richardson , mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000018097e058bc88c4e" Archived-At: Subject: Re: [Mud] How does MUD deal with broadcast IP addresses 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, 20 Jun 2019 22:05:46 -0000 --00000000000018097e058bc88c4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 20, 2019 at 5:36 PM Eliot Lear wrote: > It depends on to-device/from-device. If the device is including a > from-device and it uses multicast it should probably list it, lest an > inbound ACL simply block the traffic. For to-device, it=E2=80=99s unnece= ssary > because there are no source multicast addresses. Another way to address > this in implementations is to simply permit outbound multicast in all cas= es. > Could permitting outbound multicast for all addresses be listed as "standard mud behavior" ( in the same way as dns, ntp and dhcp are permitted by default). > > On 20 Jun 2019, at 21:28, Michael Richardson > wrote: > > > > Signed PGP part > > > > Eliot Lear wrote: > >> I like the idea of using a class for MDNS. I also think broadcast and > >> multicast are a bit of a special case, relying on the underlying ACL > >> model. What do other people think? > > > > So a MUD file for a device that should be allowed to use mDNS > > would create an ACL to 224.0.0.251? > > > > I think that internal ACLs will be very inconsistently applied by > > mud-controllers. While some will be able to hairpin all the traffic, > > other environments will make this hard, or will be too costly if there > > is a lot of traffic. > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > > > > > --=20 M. Ranganathan --00000000000018097e058bc88c4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 20, 2019 at 5:36 PM Eliot= Lear <lear@cisco.com> wrote:
It depends on to-= device/from-device.=C2=A0 If the device is including a from-device and it u= ses multicast it should probably list it, lest an inbound ACL simply block = the traffic.=C2=A0 For to-device, it=E2=80=99s unnecessary because there ar= e no source multicast addresses.=C2=A0 Another way to address this in imple= mentations is to simply permit outbound multicast in all cases.

Could permitting outbound multicast for all addres= ses be listed as "standard mud=C2=A0 behavior"=C2=A0 ( in the sam= e way as dns, ntp and dhcp are permitted by default).=C2=A0
<= br>


> On 20 Jun 2019, at 21:28, Michael Richardson <mcr+ietf@sandelman.ca> wrote= :
>
> Signed PGP part
>
> Eliot Lear <lea= r@cisco.com> wrote:
>> I like the idea of using a class for MDNS.=C2=A0 I also think broa= dcast and
>> multicast are a bit of a special case, relying on the underlying A= CL
>> model.=C2=A0 What do other people think?
>
> So a MUD file for a device that should be allowed to use mDNS
> would create an ACL to 224.0.0.251?
>
> I think that internal ACLs will be very inconsistently applied by
> mud-controllers.=C2=A0 While some will be able to hairpin all the traf= fic,
> other environments will make this hard, or will be too costly if there=
> is a lot of traffic.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>
>
>
>
>



--
M. Ranganathan

<= /div>
--00000000000018097e058bc88c4e-- From nobody Thu Jun 20 17:44:03 2019 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 A5E901200FF for ; Thu, 20 Jun 2019 17:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 54Xa1zRAqrUt for ; Thu, 20 Jun 2019 17:44:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F5E120018 for ; Thu, 20 Jun 2019 17:44:00 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 2BEFA38185; Thu, 20 Jun 2019 20:42:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A9A4B12EB; Thu, 20 Jun 2019 20:43:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A73BAE21; Thu, 20 Jun 2019 20:43:57 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: mud@ietf.org, "M. Ranganathan" In-Reply-To: References: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> <30785.1561058917@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] How does MUD deal with broadcast IP addresses 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, 21 Jun 2019 00:44:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > It depends on to-device/from-device. If the device is including a > from-device and it uses multicast it should probably list it, lest an > inbound ACL simply block the traffic. For to-device, it=E2=80=99s un= necessary > because there are no source multicast addresses. Another way to > address this in implementations is to simply permit outbound multicast > in all cases. Wouldn't to-device be about whether or not the device should receive multicast traffic? Yes, rather hard to block in many networks, but a description should still say that the device will be listening. And if one says allow it with devices from the same manufacturer, that would seem to be interesting. >> On 20 Jun 2019, at 21:28, Michael Richardson >> wrote: >> >> Signed PGP part >> >> Eliot Lear wrote: >>> I like the idea of using a class for MDNS. I also think broadcast >>> and multicast are a bit of a special case, relying on the underlying >>> ACL model. What do other people think? >> >> So a MUD file for a device that should be allowed to use mDNS would >> create an ACL to 224.0.0.251? >> >> I think that internal ACLs will be very inconsistently applied by >> mud-controllers. While some will be able to hairpin all the traffic, >> other environments will make this hard, or will be too costly if the= re >> is a lot of traffic. >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> >> >> =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0MKE0ACgkQgItw+93Q 3WVdsAf+JM+YRGtbuJLKOI3lnL9OxAR5klOBoq5jdn1S2hH94NZ+pE99GW6rs+eX f51P0AtJVx9ELpYdbPMLtv8JjsF67I1hK0RhvTrrvdDoCvULd3kUhwnirZbcbRgx HnFWQTu7dd5PaEyZHxOOD6LL/C1N5GOUC+LCgQ12Yln7R63qBXOwGoV0Dm4rUaF0 m+zNbFfQkWTiF7Lqd8AeDjzHWOdAGWixbmDRhPLFE+Av5Q787V/SbgH3ddKY/xVa zyGn5oxpZ8AAGDtnufctx6Gzbke/mRPeZ26RBoz4eJs6b1jBXefsv0040c+ruQPp RPbGGr7Jfmb3y8o+PwhJr3RJpkVZmA== =eoNU -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 21 00:01:08 2019 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 97E38120161 for ; Fri, 21 Jun 2019 00:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 71PcsLjKSMuR for ; Fri, 21 Jun 2019 00:01:04 -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 AC3CD12015D for ; Fri, 21 Jun 2019 00:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2779; q=dns/txt; s=iport; t=1561100463; x=1562310063; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=nXthvJQVNNcJqs19UB1REctil906iE1oB1B0BQuZCS0=; b=Ba9QCyM3duig4D/Aoisf78jMuuDF2A9bghGAR35FxsPxlBrGjO9mMTE/ YzwwkepaTC9kg1kslsIJ28ay1BemobVvCKy+JPM3c6B1G97S5wMMRSFOk gmZTtz8YKCMTAyYBXJCyxzdOPatAv+MRILMeDEvwgHjW80k2qpIf2d/CX E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAACpfwxd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBg1IgEiiEFoh7i2YlmmACBwEBAQkDAQE?= =?us-ascii?q?vAQGBS4J1AoMBNwYOAQMBAQQBAQIBBW2KQ4VKAQEBAwEjVgULCxgqAgJXBhO?= =?us-ascii?q?DIgGBew+oPoExgk+CeIRZEIE0AYFQiiSBf4ERJwwTgh4uPodOMoImBIwNiC2?= =?us-ascii?q?VQgmCFIIegQmQOBuXRBehAIMIAgQGBQIVgWYigVgzGggbFTsqAYJBPpBIPQM?= =?us-ascii?q?wjGUFgk0BAQ?= X-IronPort-AV: E=Sophos;i="5.63,399,1557187200"; d="asc'?scan'208";a="13357518" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jun 2019 07:01:00 +0000 Received: from ams3-vpn-dhcp5982.cisco.com (ams3-vpn-dhcp5982.cisco.com [10.61.87.93]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5L70xBn001243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jun 2019 07:01:00 GMT From: Eliot Lear Message-Id: <73F016BC-DB24-4794-A559-2B8495490997@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D3035B73-A525-42DA-B202-EF7ECD063682"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 21 Jun 2019 09:00:58 +0200 In-Reply-To: <15118.1561077837@localhost> Cc: mud@ietf.org, "M. Ranganathan" To: Michael Richardson References: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> <30785.1561058917@localhost> <15118.1561077837@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.87.93, ams3-vpn-dhcp5982.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] How does MUD deal with broadcast IP addresses 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, 21 Jun 2019 07:01:07 -0000 --Apple-Mail=_D3035B73-A525-42DA-B202-EF7ECD063682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jun 2019, at 02:43, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Eliot Lear wrote: >> It depends on to-device/from-device. If the device is including a >> from-device and it uses multicast it should probably list it, lest an >> inbound ACL simply block the traffic. For to-device, it=E2=80=99s = unnecessary >> because there are no source multicast addresses. Another way to >> address this in implementations is to simply permit outbound = multicast >> in all cases. >=20 > Wouldn't to-device be about whether or not the device should receive > multicast traffic? Yes, rather hard to block in many networks, but a > description should still say that the device will be listening. The IP address you look at for to-device is the source IP, not = destination. >=20 > And if one says allow it with devices from the same manufacturer, that = would > seem to be interesting. >=20 Yes. That=E2=80=99s what we=E2=80=99ve been doing in some cases. Eliot >=20 >>> On 20 Jun 2019, at 21:28, Michael Richardson >>> wrote: >>>=20 >>> Signed PGP part >>>=20 >>> Eliot Lear wrote: >>>> I like the idea of using a class for MDNS. I also think broadcast >>>> and multicast are a bit of a special case, relying on the = underlying >>>> ACL model. What do other people think? >>>=20 >>> So a MUD file for a device that should be allowed to use mDNS would >>> create an ACL to 224.0.0.251? >>>=20 >>> I think that internal ACLs will be very inconsistently applied by >>> mud-controllers. While some will be able to hairpin all the = traffic, >>> other environments will make this hard, or will be too costly if = there >>> is a lot of traffic. >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_D3035B73-A525-42DA-B202-EF7ECD063682 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQyAqgAKCRBugA9nE248 uJ5xAJ9ntdg2ObPk+P+K0tL1ZSWR2dcc9wCaAsk/JcY/eP61uV+FDo9kUAT1xOo= =GKm0 -----END PGP SIGNATURE----- --Apple-Mail=_D3035B73-A525-42DA-B202-EF7ECD063682-- From nobody Fri Jun 21 05:27:02 2019 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 764DE120254 for ; Fri, 21 Jun 2019 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 l4_UUna-AxLU for ; Fri, 21 Jun 2019 05:26:57 -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 341E4120253 for ; Fri, 21 Jun 2019 05:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3866; q=dns/txt; s=iport; t=1561120017; x=1562329617; h=from:mime-version:subject:message-id:date:cc:to; bh=4EM3hTZ8RkPMo4w2z5n20VHGWBYbHJASITb+bJhOhXU=; b=NnCBm0zhjynw1kDR4rzr32dVoRkH82v17eYBAI1CpLyE6ZOY3WV1XlLc ciaxuPOQkiS+uodKYCOM9/9F8+YLGSmXyAkdwD0NXryNFblGQvcR5dY4T 4YZBOHZWZFTCztNv8yx2DMDIfZ/jVH1K1l46MPzxSqHy05Gc4d7sJm/DK Q=; X-Files: signature.asc : 195 X-IronPort-AV: E=Sophos;i="5.63,400,1557187200"; d="asc'?scan'208,217";a="13363682" 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; 21 Jun 2019 12:26:55 +0000 Received: from ams3-vpn-dhcp5982.cisco.com (ams3-vpn-dhcp5982.cisco.com [10.61.87.93]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5LCQsOp021813 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jun 2019 12:26:54 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_3AD6F43C-0B0D-49D5-AFF8-2D98EBB55001"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <7AE5327A-0654-41D6-9BA7-4C5015BA4F10@cisco.com> Date: Fri, 21 Jun 2019 14:26:52 +0200 Cc: "Benoit Claise (bclaise)" , Brian Haberman To: mud@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.87.93, ams3-vpn-dhcp5982.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Mud] Building out an ARF-like capability 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, 21 Jun 2019 12:27:00 -0000 --Apple-Mail=_3AD6F43C-0B0D-49D5-AFF8-2D98EBB55001 Content-Type: multipart/alternative; boundary="Apple-Mail=_1717C8A7-FF4D-4F2A-AC01-A22EEB380DBB" --Apple-Mail=_1717C8A7-FF4D-4F2A-AC01-A22EEB380DBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m in mid draft write on this. In A World in which the device = with a mud url and mud file has its packet administratively dropped, = there are a good number of possible reasons: No controllers No devices of same manufacturer/model/ etc. Name not resolving in ACL Mismatch between what the name is resolving to and what the enforcement = point is allowing Misconfigured MUD file due to device using stuff that=E2=80=99s not = there Owned device using stuff it shouldn=E2=80=99t In all of these cases, the question arises: who wants what in a report? Deployment: Mappings at the time of drop 5-tuple Manufacturer: Limited mappings at time of drop (we don=E2=80=99t want internal IP = addresses leaving the deployment) A counter to indicate if the abstractions are filled out IP addresses of stuff using the dnsname in an ACL L4 info?? What else? Eliot --Apple-Mail=_1717C8A7-FF4D-4F2A-AC01-A22EEB380DBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99m in mid draft write on this. In A World in which the device with a = mud url and mud file has its packet administratively dropped, there are = a good number of possible reasons:

  • No controllers
  • No devices of same = manufacturer/model/ etc.
  • Name not resolving in = ACL
  • Mismatch between what the name is resolving to = and what the enforcement point is allowing
  • Misconfigured MUD file due to device using stuff that=E2=80=99s= not there
  • Owned device using stuff it = shouldn=E2=80=99t

In all of these cases, the question arises: who wants what = in a report?

Deployment:
  • Mappings at the time of drop
  • 5-tuple

Manufacturer:
  • Limited mappings at = time of drop (we don=E2=80=99t want internal IP addresses leaving the = deployment)
    • A counter to indicate if = the abstractions are filled out
    • IP addresses of stuff = using the dnsname in an ACL
    • L4 = info??

What else?

Eliot
= --Apple-Mail=_1717C8A7-FF4D-4F2A-AC01-A22EEB380DBB-- --Apple-Mail=_3AD6F43C-0B0D-49D5-AFF8-2D98EBB55001 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQzNDAAKCRBugA9nE248 uHv7AKCxdN3tjsNTVAxj8TgTd81QPOKd1wCfbNxjwtzFC3+5rIbKLVI6pfH5wLE= =jHBR -----END PGP SIGNATURE----- --Apple-Mail=_3AD6F43C-0B0D-49D5-AFF8-2D98EBB55001-- From nobody Fri Jun 21 13:58:14 2019 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 45DBD1201E0 for ; Fri, 21 Jun 2019 13:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 1QOLH37DJkl4 for ; Fri, 21 Jun 2019 13:58:10 -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 7FA6112011C for ; Fri, 21 Jun 2019 13:58:10 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B692438185; Fri, 21 Jun 2019 16:56:31 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 667D5DF2; Fri, 21 Jun 2019 16:58:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 640F9560; Fri, 21 Jun 2019 16:58:08 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: mud@ietf.org, "M. Ranganathan" In-Reply-To: <73F016BC-DB24-4794-A559-2B8495490997@cisco.com> References: <6DF69181-113E-41AB-9D59-E5D9A5293AC7@cisco.com> <30785.1561058917@localhost> <15118.1561077837@localhost> <73F016BC-DB24-4794-A559-2B8495490997@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] How does MUD deal with broadcast IP addresses 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, 21 Jun 2019 20:58:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >> Eliot Lear wrote: >>> It depends on to-device/from-device. If the device is including a >>> from-device and it uses multicast it should probably list it, lest = an >>> inbound ACL simply block the traffic. For to-device, it=E2=80=99s >>> unnecessary because there are no source multicast addresses. Anoth= er >>> way to address this in implementations is to simply permit outbound >>> multicast in all cases. >> >> Wouldn't to-device be about whether or not the device should receive >> multicast traffic? Yes, rather hard to block in many networks, but a >> description should still say that the device will be listening. > The IP address you look at for to-device is the source IP, not > destination. It took a few iterations in my brain to agree with you. It sounds, then, like it is impossible to authorize a device to receive multicast traffic. So either it's implicitly allowed or denied. It seems like we need an addendum to have a from-device list that authorizes traffic to 224.* / ff00::/8, also imply that the device can receive such traffic? How would unicast replies work? (probably I should go read the RFC again to learn if there is a specific section on this that I missed) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0NROAACgkQgItw+93Q 3WWOkQf7Bv0AFfixrJJY7GH/Um0yHuhSFXPyjoCZDIpC+SyD8l3aPNFZUGrdkCUO 9a2MuMg/lXNrTp26TMGd18IOxaR7A4HyF5dWOU2kuGNeb+tc1t1bRsO3iPr3YKtO asxpcXtVVmgzjdJycVqpVwTwOoeAtDnNQD7eptesw2mtVOge3TwXNIAJwVc2T+Ci 6skYbCt8Mp5eQhgd7S8cvphxpU8dZnx3akkcEzkWyrBwQT4wrUK0ObtQ2ja3T68F xBtL7bNCbkRd0USCZMueTkyH+XOGt5JrEYME67uaPIT2JBNUCRBxX13IdoGvotUG hAZfFEl9VRO826lve2Ka8ZUZv7DhtA== =3ZIW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 24 02:48:43 2019 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 422EF12013A; Mon, 24 Jun 2019 02:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WaHe5FTt2DPK; Mon, 24 Jun 2019 02:48:33 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215A3120033; Mon, 24 Jun 2019 02:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7756; q=dns/txt; s=iport; t=1561369712; x=1562579312; h=from:mime-version:subject:message-id:date:cc:to; bh=NQ4Kod0mJ1nykm9I2TrznMRBxJ80VrOxcUrzd8QT+uQ=; b=Cyge7XiM/i5h7hsftVUunpUohULtVjcDUe0q0DN64ZG9Onztx771Lfzh fTOKl3iQPsCRnMtkTmYJbic4umJcccVCYMSx4AB6ovqsFsWmCgOJQUIeH 1HBLgqqkWPtrMTIGUGLPOjE1RImuYe9PZnP8/sNPSvNwXEJK2qztDw5I8 Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAADYmxBd/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4MBUQEgEiGEHYh7nm+HfQIHAQEBCQMBAR8QAQGEQIMMOBM?= =?us-ascii?q?BAwEBBAEBAgEFbYo3DIV0UQVdAmCDNAGCCgijJoExihwQgTSBUYokgX+BOB+?= =?us-ascii?q?CHoNChHgygiYEi3iHbluVSAmCFgOCG4EJgyaNFRuDE4oFii+NJoZZVoF1glG?= =?us-ascii?q?IBoMIAgQGBQIVgWchgVgzGggbFWUBgkIINYIKg2mKVT0DkGABAQ?= X-IronPort-AV: E=Sophos;i="5.63,411,1557187200"; d="asc'?scan'208,217";a="13528813" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2019 09:48:30 +0000 Received: from [10.61.230.12] ([10.61.230.12]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5O9mT5k027185 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Jun 2019 09:48:29 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_75954778-D2D0-4E16-AEA7-02E72DB2FF46"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> Date: Mon, 24 Jun 2019 11:48:28 +0200 Cc: "M. Ranganathan" To: opsawg@ietf.org, mud@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.230.12, [10.61.230.12] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Mud] Declaring something to be a controller in MUD 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, 24 Jun 2019 09:48:35 -0000 --Apple-Mail=_75954778-D2D0-4E16-AEA7-02E72DB2FF46 Content-Type: multipart/alternative; boundary="Apple-Mail=_62A13398-88DA-4634-9306-0D663869EFD6" --Apple-Mail=_62A13398-88DA-4634-9306-0D663869EFD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, A few of us are just trying to put out an initial draft that addresses = one gap in MUD (there are several). In a MUD file one can say that one = wants to access a controller in two ways: either "my-controller=E2=80=9D = meaning a controller that services devices of a particular MUD URL or a = =E2=80=9Ccontroller=E2=80=9D class that services devices based on a = particular class name of controller. In either case, right now the administrator has to manually know and = populate information, to say - some device 1.2.3.4 is a controller, = either for MUD URL https://example.com/mud or = a class http://example.com/mudclass1 . = That can be laborious. To assist, we are examining ways to have a = controller declare itself as a candidate controller. That at least = provides a hint to the administrator that this particular device is = capable of serving in a particular role. To make that declaration, the device must- Form the declaration; Find the MUD manager; and Send it. Forming the declaration is easy: we can make this a YANG grouping and = then place it in various spots. Finding the MUD manager depends on one question: Was the device built to be a controller or is it a general purpose = device that has an app that is intended to be a controller? If the device was built to be a controller, we can simply cram the = declaration into that devices own MUD file as an extension. If the = device is a general purpose computer, things get a bit more interesting. = In this case we have two choices: Either create a MUD file that points somewhere internally - this = doesn=E2=80=99t seem very plug and play. Make the declaration directly to the MUD manager. I=E2=80=99m going to focus on the latter for the moment. It is easy = enough to create a RESTful interface for this purpose, but it requires a = mechanism to discovered the MUD manager, which up until now has been an = internal part of the network infrastructure. Let me call this out plainly: letting the app itself directly call the = MUD manager requires that the MUD manager itself become exposed to the = user infrastructure, which is a change. One possibility to address this is to incorporate the new RESTful = endpoint into an ANIMA BRSKI join registrar, which may already be = exposed. But that requires that ANIMA BRSKI be in play, which it may = not. My thinking is that we do this work in two stages. First handle the = easy case, which is the MUD file extension, and then figure out how to = do the app version of this. Thoughts? Eliot --Apple-Mail=_62A13398-88DA-4634-9306-0D663869EFD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

A few of = us are just trying to put out an initial draft that addresses one gap in = MUD (there are several).  In a MUD file one can say that one wants = to access a controller in two ways: either "my-controller=E2=80=9D = meaning a controller that services devices of a particular MUD URL or a = =E2=80=9Ccontroller=E2=80=9D class that services devices based on a = particular class name of controller.

In either case, right now the = administrator has to manually know and populate information, to say - = some device 1.2.3.4 is a controller, either for MUD URL https://example.com/mud or a class http://example.com/mudclass1.  That can be = laborious.  To assist, we are examining ways to have a controller = declare itself as a candidate controller.  That at least provides a = hint to the administrator that this particular device is capable of = serving in a particular role.

To make that declaration, the device = must-
  • Form = the declaration;
  • Find the MUD manager; and
  • Send it.

Forming the declaration is easy: = we can make this a YANG grouping and then place it in various = spots.

Finding = the MUD manager depends on one question:
  • Was the device built to be a = controller or is it a general purpose device that has an app that is = intended to be a controller?

If the device was built to be a = controller, we can simply cram the declaration into that devices own MUD = file as an extension.  If the device is a general purpose computer, = things get a bit more interesting.  In this case we have two = choices:

  • Either create a MUD file that = points somewhere internally - this doesn=E2=80=99t seem very plug and = play.
  • Make the declaration directly to the MUD = manager.

I=E2=80=99m going to focus on the latter for the moment. =  It is easy enough to create a RESTful interface for this purpose, = but it requires a mechanism to discovered the MUD manager, which up = until now has been an internal part of the network = infrastructure.

Let me call this out plainly: letting the app itself directly = call the MUD manager requires that the MUD manager itself become exposed = to the user infrastructure, which is a change.

One possibility to address this is to = incorporate the new RESTful endpoint into an ANIMA BRSKI join registrar, = which may already be exposed.  But that requires that ANIMA BRSKI = be in play, which it may not.

My thinking is that we do this work in = two stages.  First handle the easy case, which is the MUD file = extension, and then figure out how to do the app version of = this.

Thoughts?

Eliot

= --Apple-Mail=_62A13398-88DA-4634-9306-0D663869EFD6-- --Apple-Mail=_75954778-D2D0-4E16-AEA7-02E72DB2FF46 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----- iFwEARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXRCcbAAKCRBugA9nE248 uJW/AJ0QqCMr6yJP/AMrYG80yHZkZKjXOQCY0H0YFcr8ujxp9yYWlFRSy1TAaQ== =7bd0 -----END PGP SIGNATURE----- --Apple-Mail=_75954778-D2D0-4E16-AEA7-02E72DB2FF46-- From nobody Mon Jun 24 09:03:04 2019 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 6915A1204C3; Mon, 24 Jun 2019 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 abg1qjBq7vAN; Mon, 24 Jun 2019 09:02:59 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 8EF86120369; Mon, 24 Jun 2019 09:02:59 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id s7so97000iob.11; Mon, 24 Jun 2019 09:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pTBFoAzsKnuwma825Y6VqljnQr+CSFXhqX8v/IR+QGc=; b=BoambRudgFfYhTOdaOftZq3ClhuzXC5NvLsq5zlaErAFE0DoHsE0kaMeKDegEJQU5s /Oksez+yAv957nMNgsDeIV6IvLVktl/GAckF2UfShb/Sz4LjU0H4Ae+tlOzzSE0CbL1z 46ohDWmd7MruMYPumr8MO2zNPAn/6ptFvw0xd8+3hF7QJ6bKou2Ep5fTJpdKcIgwpEmU YP16QlhV1O892yMJEIIAqADOUaIlgiVES7Uob3RINInmeJZEbDJwKlgGYF9EhfGCUlei WDt9Ulbs2z+otF5I9dro28uhepuAg5AmtWHioRyKZSlWR352IOubT2yp2Hca3w2za1lz HKzg== 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=pTBFoAzsKnuwma825Y6VqljnQr+CSFXhqX8v/IR+QGc=; b=HG4Epl0g+zeokcKTE1JvZC6vDnRVd80AFQcUoUUP8TZm/NNm99lMLriQQSPDTum175 7zUg7sG9TzFkMYc6WBUWQZgydCcqBRB7wifu1TEgvG2I/6/83IzVbBgYgXA5vizIJYBn S7pqw1sQaaZKDFAErrKezF8VJ81mQ56dPVT875Qo7zsRKHi+9xnDVe8ZEl3uY0o6rYdf NvAFW3ldwJ0h55z05qT5j7p4Wcq2/wxT16ja8UmtyfciOcHc7wFt5CihiWIpMGAtzXwh c+xHhwM3RJVFDpq4aIw9oLOONM+ijw3YOmn9/nEumWHwd+2Kj27QCGdtusN1SrUOD9bn zp0Q== X-Gm-Message-State: APjAAAWxvnt+yB591jGN/Yf6o8uC4EzQap++JqjCZFc5FDczRc4fbGBB ezAajgK5n08wUI3meBbQzc4Sud7HxGd6EO9DrDY= X-Google-Smtp-Source: APXvYqx+VNJAS8cxxQQMysTBt3ccxvSayWqx/JKFv5MVbQ4RuWaWu35sSyEq6b0Y6bCrXEP3QDCldMpguOHZfneLqAI= X-Received: by 2002:a05:6602:2252:: with SMTP id o18mr3476907ioo.63.1561392178520; Mon, 24 Jun 2019 09:02:58 -0700 (PDT) MIME-Version: 1.0 References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> In-Reply-To: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> From: "M. Ranganathan" Date: Mon, 24 Jun 2019 12:02:21 -0400 Message-ID: To: Eliot Lear Cc: opsawg@ietf.org, mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000027e8e3058c13f2f3" Archived-At: Subject: Re: [Mud] Declaring something to be a controller in MUD 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, 24 Jun 2019 16:03:03 -0000 --00000000000027e8e3058c13f2f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eliot, On Mon, Jun 24, 2019 at 5:48 AM Eliot Lear wrote: > Hi everyone, > > A few of us are just trying to put out an initial draft that addresses on= e > gap in MUD (there are several). In a MUD file one can say that one wants > to access a controller in two ways: either "my-controller=E2=80=9D meanin= g a > controller that services devices of a particular MUD URL or a =E2=80=9Cco= ntroller=E2=80=9D > class that services devices based on a particular class name of controlle= r. > > In either case, right now the administrator has to manually know and > populate information, to say - some device 1.2.3.4 is a controller, eithe= r > for MUD URL https://example.com/mud or a class > http://example.com/mudclass1. That can be laborious. To assist, we are > examining ways to have a controller declare itself as a candidate > controller. That at least provides a hint to the administrator that this > particular device is capable of serving in a particular role. > > To make that declaration, the device must- > > - Form the declaration; > - Find the MUD manager; and > - Send it. > > > Forming the declaration is easy: we can make this a YANG grouping and the= n > place it in various spots. > > Finding the MUD manager depends on one question: > > - Was the device built to be a controller or is it a general purpose > device that has an app that is intended to be a controller? > > > If the device was built to be a controller, we can simply cram the > declaration into that devices own MUD file as an extension. If the devic= e > is a general purpose computer, things get a bit more interesting. In thi= s > case we have two choices: > > > - Either create a MUD file that points somewhere internally - this > doesn=E2=80=99t seem very plug and play. > - Make the declaration directly to the MUD manager. > > > I=E2=80=99m going to focus on the latter for the moment. It is easy enou= gh to > create a RESTful interface for this purpose, but it requires a mechanism = to > discovered the MUD manager, which up until now has been an internal part = of > the network infrastructure. > > Let me call this out plainly: letting the app itself directly call the MU= D > manager requires that the MUD manager itself become exposed to the user > infrastructure, which is a change. > Regardless of whether the app directly calls the MUD manager or the Join registrar calls the MUD manager, an interface to it would need to be defined so that the MUD manager can be notified. A RESTful interface should work fine. Of course the RESTful API should be secured and based on certificates/HTTPs but that problem has been solved so does not need to be re-defined here. Of greater concern is that it is exposed outside the NW infrastructure. However, it does not HAVE to be exposed -- the same interface can work in either case (i.e. the Join registrar can use it or the controller application can use it, with the recommendation that it SHOULD not be exposed). As you rightly point out, discovery protocols are dime a dozen so pick a simple one. Can DNS (SRV record) be defined/used to locate the MUD manager? Perhaps it can be sent back in the DHCP response in case the service needs to be exposed to the application (just thinking out loud). > One possibility to address this is to incorporate the new RESTful endpoin= t > into an ANIMA BRSKI join registrar, which may already be exposed. But th= at > requires that ANIMA BRSKI be in play, which it may not. > > My thinking is that we do this work in two stages. First handle the easy > case, which is the MUD file extension, and then figure out how to do the > app version of this. > Sounds good. Regards, Ranga > > Thoughts? > > Eliot > > --=20 M. Ranganathan --00000000000027e8e3058c13f2f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Eliot,


On Mon, Jun 24, 2019 at 5:48 AM Eliot Lear <lear@cisco.com> wrote:
Hi everyone,

A few of us are just trying to put out a= n initial draft that addresses one gap in MUD (there are several).=C2=A0 In= a MUD file one can say that one wants to access a controller in two ways: = either "my-controller=E2=80=9D meaning a controller that services devi= ces of a particular MUD URL or a =E2=80=9Ccontroller=E2=80=9D class that se= rvices devices based on a particular class name of controller.
In either case, right now the administrator has to manually kn= ow and populate information, to say - some device 1.2.3.4 is a controller, = either for MUD URL ht= tps://example.com/mud=C2=A0or a class http://example.com/mudclass1.=C2=A0 That can = be laborious.=C2=A0 To assist, we are examining ways to have a controller d= eclare itself as a candidate controller.=C2=A0 That at least provides a hin= t to the administrator that this particular device is capable of serving in= a particular role.

To make that declaration, the = device must-
  • Form the declaration;
  • Find the MUD manager; and
  • Send = it.

Forming the declaration is easy: we = can make this a YANG grouping and then place it in various spots.

Finding the MUD manager depends on one question:
=
  • Was the device bu= ilt to be a controller or is it a general purpose device that has an app th= at is intended to be a controller?

If th= e device was built to be a controller, we can simply cram the declaration i= nto that devices own MUD file as an extension.=C2=A0 If the device is a gen= eral purpose computer, things get a bit more interesting.=C2=A0 In this cas= e we have two choices:

  • Either create a MUD file that points somewhe= re internally - this doesn=E2=80=99t seem very plug and play.
  • Make = the declaration directly to the MUD manager.

=
I=E2=80=99m going to focus on the latter for the moment.=C2=A0 It is e= asy enough to create a RESTful interface for this purpose, but it requires = a mechanism to discovered the MUD manager, which up until now has been an i= nternal part of the network infrastructure.

Let me= call this out plainly: letting the app itself directly call the MUD manage= r requires that the MUD manager itself become exposed to the user infrastru= cture, which is a change.

Regar= dless of whether the app directly calls the MUD manager or the Join registr= ar calls the MUD manager, an interface to it would need to be defined so th= at the MUD manager can be notified.

A RESTful = interface should work fine. Of course the RESTful API should be secured and= based on certificates/HTTPs but that problem has been solved so does not n= eed to be re-defined here. Of greater concern is that it is exposed outside= the NW infrastructure. However, it does not HAVE to be exposed -- the same= interface can work in either case (i.e. the Join registrar can use it or t= he controller=C2=A0 application can use it, with the recommendation that it= SHOULD not be exposed).

As you rightly point= out, discovery protocols are dime a dozen so pick a simple one. Can DNS (S= RV record) be defined/used to locate the MUD manager?=C2=A0 Perhaps it can = be sent back in the DHCP response in case the service needs to be exposed t= o the application (just thinking out loud).

<= br>

One possibility to address th= is is to incorporate the new RESTful endpoint into an ANIMA BRSKI join regi= strar, which may already be exposed.=C2=A0 But that requires that ANIMA BRS= KI be in play, which it may not.

My thinking is th= at we do this work in two stages.=C2=A0 First handle the easy case, which i= s the MUD file extension, and then figure out how to do the app version of = this.

Sounds good.
Regards, Ranga

T= houghts?

Eliot



--
M. Ranganathan

--00000000000027e8e3058c13f2f3-- From nobody Tue Jun 25 12:52:35 2019 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 B014A1202B5; Tue, 25 Jun 2019 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 wT_FLF1Vhm82; Tue, 25 Jun 2019 12:52:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C6A120044; Tue, 25 Jun 2019 12:52:30 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8546D380BE; Tue, 25 Jun 2019 15:50:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7F4C0109C; Tue, 25 Jun 2019 15:52:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7CE22E8C; Tue, 25 Jun 2019 15:52:26 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: opsawg@ietf.org, mud@ietf.org In-Reply-To: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Declaring something to be a controller in MUD 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, 25 Jun 2019 19:52:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > A few of us are just trying to put out an initial draft that addresses > one gap in MUD (there are several). > In a MUD file one can say that one > wants to access a controller in two ways: either "my-controller=E2=80= =9D > meaning a controller that services devices of a particular MUD URL or= a > =E2=80=9Ccontroller=E2=80=9D class that services devices based on a p= articular class > name of controller. I think that we have two potential avenues for security attacks here: 1) a device that claims to be a controller in order to gain access to devices. 2) devices that claim to be belong to a controller in order to attack controllers. To my mind there are some different things we could do: 1) insist that to user the my-controller connections that the two devices have to be signed by the "same" entity. ["same" could mean literal the same key, the same certificate Issuer/DN, or something more complex] 2) we could have devices declare in an MUD extension the DN/certificate/entity which must sign their controller device. 3) (2) above, but with some level of indirection through some URL. > In either case, right now the administrator has to manually know and > populate information, to say - some device 1.2.3.4 is a controller, > either for MUD URL https://example.com/mud = or > a class http://example.com/mudclass1 . > That can be laborious. To assist, we are examining ways to have a > controller declare itself as a candidate controller. That at least > provides a hint to the administrator that this particular device is > capable of serving in a particular role. I think that anything that requires administrator activity to be a fail for residential use. It's too complex. > To make that declaration, the device must- Form the declaration; Find > the MUD manager; and Send it. > Finding the MUD manager depends on one question: Was the device built > to be a controller or is it a general purpose device that has an app > that is intended to be a controller? > If the device was built to be a controller, we can simply cram the > declaration into that devices own MUD file as an extension. If the > device is a general purpose computer, things get a bit more > interesting. Yes... but I think that we have to solve the multi-purpose computer MUD anyway. The intelligent speakers (Echo,Home,Mycroft,etc.) need to gain new MUD definitions as they gain "skills", and I think that we can treat a smartphone in a similar way. This might be a place where IPv6 wins, if we can split off each skill into a new provisioning domain, giving it a new IPv6 IID. I was thinking that may= be we can associate the private key that signed the MUD file to the IID via something like SEND/CGA, but I'm not sure how many private keys we have (one for the app developer, or one per app installed on each device). > In this case we have two choices: > Either create a MUD file that points somewhere internally - this > doesn=E2=80=99t seem very plug and play. Make the declaration direct= ly to the > MUD manager. > I=E2=80=99m going to focus on the latter for the moment. It is easy = enough to > create a RESTful interface for this purpose, but it requires a > mechanism to discovered the MUD manager, which up until now has been = an > internal part of the network infrastructure. > Let me call this out plainly: letting the app itself directly call the > MUD manager requires that the MUD manager itself become exposed to the > user infrastructure, which is a change. Agreed. And that the MUD manager have some reason to trust the device is not p0wned, and sending a bogus MUD file up. A certificate chain back to the manufacturer is not enough, it has to be signed by a key that an attacker can't get access to. So that requires attested keys if they are "local", or for the signature to be done elsewhere. > One possibility to address this is to incorporate the new RESTful > endpoint into an ANIMA BRSKI join registrar, which may already be > exposed. But that requires that ANIMA BRSKI be in play, which it may > not. It is, however, a really good idea for the case where it is in play. > My thinking is that we do this work in two stages. First handle the > easy case, which is the MUD file extension, and then figure out how to > do the app version of this. > Thoughts? yes. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0Se3oACgkQgItw+93Q 3WUp5Qf6A3EJ2RigrbmeApBt25KdwvLUmHQS4XFakGQklHDY6Wi2w4XWAyxaBg9i DQu7za/MQbGsNOwUdQ7tcGykFZaZ8T184bccrar+PxgzvtUyG3vReFUZYc/87pmX XBdnYwW+5mQCTsdNFAc1nv72UNg1J8Ut6KAeQug1wdLTEq/yFkg9a1U5klJDitu5 PnJ6nswfySj/5aqnYuVJ5Ol3DdnYTtx6hZCyD26wRjm3BLLBihcVU1ET90sJ+Q88 y1X1XZVMhJZlzZ4KUMzFWxP4KP0wc0vEj+nB9HS0B7WS8HGn639QeJ8WsNjNNhex 2/hMOb+R5R9b504ESq7yVCuN6Z7q5A== =7mfs -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 26 03:56:20 2019 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 8B20212025D; Wed, 26 Jun 2019 03:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 J16sFv_DR7xr; Wed, 26 Jun 2019 03:56:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BBF1200C1; Wed, 26 Jun 2019 03:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6159; q=dns/txt; s=iport; t=1561546575; x=1562756175; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Esjp0X2zAWZKwV0qVAAaQ+JfZdloaEfdo8dv42O3MCQ=; b=VHygwCC+1kNEfQu7hTtlqPs6JAfe6WVLFbAubE7NhV/gn5UCxbb/PHDQ ny7QK0dt+ZdT92yHUGACFnmsvFIMM3B4jxMjUzrRDF7PPwMe+kPdAzJOe LEQotO8kKR6vHJHAajAhStuCCTwfslSQ3SpvQo0OP+J3yyEIbFDu9T8p7 g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AABTThNd/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZ4MBUQEyIQeEFYh7i18lmmcCBwEBAQkDAQEfEAEBgUu?= =?us-ascii?q?CdQKDIDgTAQMBAQQBAQIBBW2KNwyFSgEBAQMBI0kIAgMFCwsYKgICVwYTgyI?= =?us-ascii?q?BgXsPCKUtgTGFR4RgEIE0gVGHRIJggX+BEScME4IeLj6CVoR4MoImBIwBGod?= =?us-ascii?q?VWodZjXcJghiCHoEKgyiEZIg7G4MWigqKNJQIWIF3glOIDYMJAgQGBQIVgWc?= =?us-ascii?q?hgVgzGggbFWUBgkEJNYIKBReDTYpVPQMwjysBAQ?= X-IronPort-AV: E=Sophos;i="5.63,419,1557187200"; d="asc'?scan'208";a="13612955" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2019 10:56:12 +0000 Received: from [10.61.211.92] ([10.61.211.92]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QAuCLM011870 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jun 2019 10:56:12 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_59B572DF-B462-4ADC-9CBB-C9EC9E0BC6C7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Jun 2019 12:56:10 +0200 In-Reply-To: <1547.1561492346@localhost> Cc: opsawg@ietf.org, mud@ietf.org To: Michael Richardson References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.211.92, [10.61.211.92] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] [OPSAWG] Declaring something to be a controller in MUD 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, 26 Jun 2019 10:56:19 -0000 --Apple-Mail=_59B572DF-B462-4ADC-9CBB-C9EC9E0BC6C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 Jun 2019, at 21:52, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Eliot Lear wrote: >> A few of us are just trying to put out an initial draft that = addresses >> one gap in MUD (there are several). >=20 >> In a MUD file one can say that one >> wants to access a controller in two ways: either "my-controller=E2=80=9D= >> meaning a controller that services devices of a particular MUD URL or = a >> =E2=80=9Ccontroller=E2=80=9D class that services devices based on a = particular class >> name of controller. >=20 > I think that we have two potential avenues for security attacks here: > 1) a device that claims to be a controller in order to gain access to > devices. > 2) devices that claim to be belong to a controller in order to attack > controllers. >=20 > To my mind there are some different things we could do: >=20 > 1) insist that to user the my-controller connections that the two = devices > have to be signed by the "same" entity. ["same" could mean literal = the > same key, the same certificate Issuer/DN, or something more = complex] >=20 > 2) we could have devices declare in an MUD extension the > DN/certificate/entity which must sign their controller device. >=20 > 3) (2) above, but with some level of indirection through some URL. I could see these as options. >=20 >> In either case, right now the administrator has to manually know and >> populate information, to say - some device 1.2.3.4 is a controller, >> either for MUD URL https://example.com/mud = or >> a class http://example.com/mudclass1 . >> That can be laborious. To assist, we are examining ways to have a >> controller declare itself as a candidate controller. That at least >> provides a hint to the administrator that this particular device is >> capable of serving in a particular role. >=20 > I think that anything that requires administrator activity to be a = fail for > residential use. It's too complex. There will ALWAYS be a need for an administrator in the enterprise case. = But maybe with the options above we can ease the consumer burden over = time. In the consumer case, you might want an app for initial device = admission control anyway, no? Can we not rely on that interaction as an = approval step in this instance? >=20 >> To make that declaration, the device must- Form the declaration; Find >> the MUD manager; and Send it. >=20 >> Finding the MUD manager depends on one question: Was the device built >> to be a controller or is it a general purpose device that has an app >> that is intended to be a controller? >=20 >> If the device was built to be a controller, we can simply cram the >> declaration into that devices own MUD file as an extension. If the >> device is a general purpose computer, things get a bit more >> interesting. >=20 > Yes... but I think that we have to solve the multi-purpose computer = MUD > anyway. The intelligent speakers (Echo,Home,Mycroft,etc.) need to = gain new > MUD definitions as they gain "skills", and I think that we can treat a > smartphone in a similar way. >=20 > This might be a place where IPv6 wins, if we can split off each skill = into a > new provisioning domain, giving it a new IPv6 IID. I was thinking = that maybe > we can associate the private key that signed the MUD file to the IID = via > something like SEND/CGA, but I'm not sure how many private keys we = have > (one for the app developer, or one per app installed on each device). >=20 >> In this case we have two choices: >=20 >> Either create a MUD file that points somewhere internally - this >> doesn=E2=80=99t seem very plug and play. Make the declaration = directly to the >> MUD manager. >=20 >> I=E2=80=99m going to focus on the latter for the moment. It is easy = enough to >> create a RESTful interface for this purpose, but it requires a >> mechanism to discovered the MUD manager, which up until now has been = an >> internal part of the network infrastructure. >=20 >> Let me call this out plainly: letting the app itself directly call = the >> MUD manager requires that the MUD manager itself become exposed to = the >> user infrastructure, which is a change. >=20 > Agreed. > And that the MUD manager have some reason to trust the device is not = p0wned, > and sending a bogus MUD file up. A certificate chain back to the > manufacturer is not enough, it has to be signed by a key that an = attacker > can't get access to. So that requires attested keys if they are = "local", or > for the signature to be done elsewhere. >=20 >> One possibility to address this is to incorporate the new RESTful >> endpoint into an ANIMA BRSKI join registrar, which may already be >> exposed. But that requires that ANIMA BRSKI be in play, which it may >> not. >=20 > It is, however, a really good idea for the case where it is in play. >=20 >> My thinking is that we do this work in two stages. First handle the >> easy case, which is the MUD file extension, and then figure out how = to >> do the app version of this. >=20 >> Thoughts? >=20 > yes. >=20 Was that =E2=80=9Cyes=E2=80=9D to the two stage approach? Eliot > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_59B572DF-B462-4ADC-9CBB-C9EC9E0BC6C7 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXRNPSgAKCRBugA9nE248 uB6SAJ9WKlB4UK9mpWxyhs5Yqc/aSWcxXwCg5uA13HZfOBrMBOeNwleyNe7MgSI= =tI3V -----END PGP SIGNATURE----- --Apple-Mail=_59B572DF-B462-4ADC-9CBB-C9EC9E0BC6C7-- From nobody Wed Jun 26 04:15:59 2019 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 2211912025D; Wed, 26 Jun 2019 04:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 jxjot-QYKnSQ; Wed, 26 Jun 2019 04:15:48 -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 C3438120253; Wed, 26 Jun 2019 04:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6302; q=dns/txt; s=iport; t=1561547748; x=1562757348; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=bfDVLIcicq9dEsMtQ4ZGpOrc4coIgKS5K43wXEj2y9w=; b=HtmHZTjPAgYWktzLTHWlG8Qkzwxrf2goDiuLRMnlQYyQ8oXKwo+cB/L/ IpVc7R3okU3cMAVnNGQt7m8Y9YrNZLLi3Z/TK8n206+xZoJ4+n9hNeWaF WUM259rcrxn2T8LaBggRLnip8Uk0saT6q6VjIK/3sAQmLGy9u0uvnzE56 U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AAB4UxNd/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZ4MBUQEyIQeEFYh7i18lmmcCBwEBAQkDAQEjDAEBgUu?= =?us-ascii?q?CdQKDIDgTAQMBAQQBAQIBBW2KNwyFSgEBAQMBI0kIAgMFCwsYKgICVwYTgyI?= =?us-ascii?q?BgXsPCAelMIExhUeEYBCBNIFRh0SCYIF/gREnDBOCHi4+glaEeDKCJgSMARq?= =?us-ascii?q?HVVqVUAmCGIIegQqDKIRkiDsbgxaKCoo0lAhYgXeCU4gNgwkCBAYFAhWBZyG?= =?us-ascii?q?BWDMaCBsVOyoBgkEJNYIKBReDTYpVPQMwjysBAQ?= X-IronPort-AV: E=Sophos;i="5.63,419,1557187200"; d="asc'?scan'208";a="13551023" 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; 26 Jun 2019 11:15:45 +0000 Received: from [10.61.211.92] ([10.61.211.92]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QBFiSM015121 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jun 2019 11:15:44 GMT From: Eliot Lear Message-Id: <14059460-C481-4E4C-977B-135F9F45C5D9@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_87042D5B-63C4-44C2-88C4-190EB8743177"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Jun 2019 13:15:41 +0200 In-Reply-To: <1547.1561492346@localhost> Cc: opsawg@ietf.org, mud@ietf.org To: Michael Richardson References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.211.92, [10.61.211.92] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] [OPSAWG] Declaring something to be a controller in MUD 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, 26 Jun 2019 11:15:51 -0000 --Apple-Mail=_87042D5B-63C4-44C2-88C4-190EB8743177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 Jun 2019, at 21:52, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Eliot Lear wrote: >> A few of us are just trying to put out an initial draft that = addresses >> one gap in MUD (there are several). >=20 >> In a MUD file one can say that one >> wants to access a controller in two ways: either "my-controller=E2=80=9D= >> meaning a controller that services devices of a particular MUD URL or = a >> =E2=80=9Ccontroller=E2=80=9D class that services devices based on a = particular class >> name of controller. >=20 > I think that we have two potential avenues for security attacks here: > 1) a device that claims to be a controller in order to gain access to > devices. > 2) devices that claim to be belong to a controller in order to attack > controllers. >=20 > To my mind there are some different things we could do: >=20 > 1) insist that to user the my-controller connections that the two = devices > have to be signed by the "same" entity. ["same" could mean literal = the > same key, the same certificate Issuer/DN, or something more = complex] >=20 > 2) we could have devices declare in an MUD extension the > DN/certificate/entity which must sign their controller device. >=20 > 3) (2) above, but with some level of indirection through some URL. Another thought here: We could provide a level of dereference for authorized controllers in = the device=E2=80=99s MUD file, in the form of a URL list that would look = something like: { [ =E2=80=9Ccontroller=E2=80=9D : =E2=80=9Ccontroller-name" =E2=80=9Cmud-urls=E2=80=9D : [ some mud urls of valid controllers = here ] =E2=80=9Cinclude=E2=80=9D : = =E2=80=9Chttps://levelofindirection.example.com=E2=80=9D that points to = a file that contains a JSON serialization of this grouping } Whether you trust that mud-url without a cert is up to you. Eliot >=20 >> In either case, right now the administrator has to manually know and >> populate information, to say - some device 1.2.3.4 is a controller, >> either for MUD URL https://example.com/mud = or >> a class http://example.com/mudclass1 . >> That can be laborious. To assist, we are examining ways to have a >> controller declare itself as a candidate controller. That at least >> provides a hint to the administrator that this particular device is >> capable of serving in a particular role. >=20 > I think that anything that requires administrator activity to be a = fail for > residential use. It's too complex. >=20 >> To make that declaration, the device must- Form the declaration; Find >> the MUD manager; and Send it. >=20 >> Finding the MUD manager depends on one question: Was the device built >> to be a controller or is it a general purpose device that has an app >> that is intended to be a controller? >=20 >> If the device was built to be a controller, we can simply cram the >> declaration into that devices own MUD file as an extension. If the >> device is a general purpose computer, things get a bit more >> interesting. >=20 > Yes... but I think that we have to solve the multi-purpose computer = MUD > anyway. The intelligent speakers (Echo,Home,Mycroft,etc.) need to = gain new > MUD definitions as they gain "skills", and I think that we can treat a > smartphone in a similar way. >=20 > This might be a place where IPv6 wins, if we can split off each skill = into a > new provisioning domain, giving it a new IPv6 IID. I was thinking = that maybe > we can associate the private key that signed the MUD file to the IID = via > something like SEND/CGA, but I'm not sure how many private keys we = have > (one for the app developer, or one per app installed on each device). >=20 >> In this case we have two choices: >=20 >> Either create a MUD file that points somewhere internally - this >> doesn=E2=80=99t seem very plug and play. Make the declaration = directly to the >> MUD manager. >=20 >> I=E2=80=99m going to focus on the latter for the moment. It is easy = enough to >> create a RESTful interface for this purpose, but it requires a >> mechanism to discovered the MUD manager, which up until now has been = an >> internal part of the network infrastructure. >=20 >> Let me call this out plainly: letting the app itself directly call = the >> MUD manager requires that the MUD manager itself become exposed to = the >> user infrastructure, which is a change. >=20 > Agreed. > And that the MUD manager have some reason to trust the device is not = p0wned, > and sending a bogus MUD file up. A certificate chain back to the > manufacturer is not enough, it has to be signed by a key that an = attacker > can't get access to. So that requires attested keys if they are = "local", or > for the signature to be done elsewhere. >=20 >> One possibility to address this is to incorporate the new RESTful >> endpoint into an ANIMA BRSKI join registrar, which may already be >> exposed. But that requires that ANIMA BRSKI be in play, which it may >> not. >=20 > It is, however, a really good idea for the case where it is in play. >=20 >> My thinking is that we do this work in two stages. First handle the >> easy case, which is the MUD file extension, and then figure out how = to >> do the app version of this. >=20 >> Thoughts? >=20 > yes. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_87042D5B-63C4-44C2-88C4-190EB8743177 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXRNT3QAKCRBugA9nE248 uKnyAJ470WteMz46iB8uD5N/bcXHSbHEbwCgq9wzLD2F0VqZ/dwytMllLW8QRTk= =ZRow -----END PGP SIGNATURE----- --Apple-Mail=_87042D5B-63C4-44C2-88C4-190EB8743177-- From nobody Wed Jun 26 07:27:40 2019 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 478A3120191; Wed, 26 Jun 2019 07:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pgG46YaQL0lW; Wed, 26 Jun 2019 07:27:31 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 153B5120189; Wed, 26 Jun 2019 07:27:31 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id r185so5473057iod.6; Wed, 26 Jun 2019 07:27:31 -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=xc5p2uLi5UB/mWJ8hmCFkGe7KoIMUywDxm1Jgsx0DBU=; b=mmRdjhybuaeXAASdMqL3sIkbWkj4Pck2eXCowEe6W4xL8RltX8T6rz33SXT/B06R+F NAm0dMV+4cRktrwtWP5l2F4QVAkya8gxaGkh2rdFzKr4n7E0QXDW1mWn2BmZ3+JRAD1d YEZFc6qdLq9KvJIX6OnGxScbdEaJgJaU9yvV4bfy+c3xMHKBjkaf4EZGS0jGufwzIPBC 8VpHefVxXVJv0jrX2pmrUDDPAJKnVrd32Kfvxmw1/1Rqjy/ptIJltXzz0JELFeBVTeM6 6SiKmOCgpqlEgWsYnil8UlCD1ubMuhFau+Q52IlIPpLhkteGZdBqVmfIb3zmI9fIfMQ6 prGg== 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=xc5p2uLi5UB/mWJ8hmCFkGe7KoIMUywDxm1Jgsx0DBU=; b=AzjMmobD6GEF5RT2Yh6ZehJM7/qR/bJgpeUrr9EvASk0YuRVH4Y0cS28XlJKLLdHGO G5L9lveNhuIL64gxgLL/eusmcA+3r0ldiHOyLo5vZ+G8hUuLD/zwkYtbInujKJTQ1317 3lm+z0qa9Y6c+EFh14P9ALAV9LIEdbmxfTxsQZUCbCPBArp/WeT9OfdelD2tjpNT1Mpy Pbr+3boBicVOT0cEy0/NKi/xq0bkMLQy0aqUcWVEDKaO0/Sfd2qAJUp9/qOz4cGsohh6 5odZVbmUSNyWe2wEkvjZWrvTgOiB91JoxgjqlnUFPIytJfnaLamolVPBIeB3m/zJtvb5 WTOA== X-Gm-Message-State: APjAAAXaKdUDR+JuwcbfEVGcRQPFxozrjHW2Bx8h62fbuYrQQKyXchP4 DfdhEKIgYvoIq2upGIJPrjeBlYs2FjZi9/ph6o8= X-Google-Smtp-Source: APXvYqwee6+EFsY2ZheXBDFZnl4aLand6pxBiCi/3toptGMje9XalkPvLKcMzb2NGlEijbbr/JrvZqwgP0c4T0dOJlA= X-Received: by 2002:a5e:d615:: with SMTP id w21mr5620227iom.0.1561559250082; Wed, 26 Jun 2019 07:27:30 -0700 (PDT) MIME-Version: 1.0 References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> In-Reply-To: From: "M. Ranganathan" Date: Wed, 26 Jun 2019 10:26:53 -0400 Message-ID: To: Eliot Lear Cc: Michael Richardson , opsawg@ietf.org, mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000065a6c9058c3ad84d" Archived-At: Subject: Re: [Mud] [OPSAWG] Declaring something to be a controller in MUD 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, 26 Jun 2019 14:27:38 -0000 --00000000000065a6c9058c3ad84d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 26, 2019 at 6:56 AM Eliot Lear wrote: > > > > On 25 Jun 2019, at 21:52, Michael Richardson > wrote: > > > > Signed PGP part > > > > Eliot Lear wrote: > >> A few of us are just trying to put out an initial draft that addresses > >> one gap in MUD (there are several). > > > >> In a MUD file one can say that one > >> wants to access a controller in two ways: either "my-controller=E2=80= =9D > >> meaning a controller that services devices of a particular MUD URL or = a > >> =E2=80=9Ccontroller=E2=80=9D class that services devices based on a pa= rticular class > >> name of controller. > > > > I think that we have two potential avenues for security attacks here: > > 1) a device that claims to be a controller in order to gain access to > > devices. > > 2) devices that claim to be belong to a controller in order to attack > > controllers. > > > > To my mind there are some different things we could do: > > > > 1) insist that to user the my-controller connections that the two devic= es > > have to be signed by the "same" entity. ["same" could mean literal t= he > > same key, the same certificate Issuer/DN, or something more complex] > > > > 2) we could have devices declare in an MUD extension the > > DN/certificate/entity which must sign their controller device. > controller or my-controller could refer to an application (not necessarily another device). However, the approach you are suggesting could apply to an application as well. > > > 3) (2) above, but with some level of indirection through some URL. > > > I could see these as options. > > > > >> In either case, right now the administrator has to manually know and > >> populate information, to say - some device 1.2.3.4 is a controller, > >> either for MUD URL https://example.com/mud o= r > >> a class http://example.com/mudclass1 . > >> That can be laborious. To assist, we are examining ways to have a > >> controller declare itself as a candidate controller. That at least > >> provides a hint to the administrator that this particular device is > >> capable of serving in a particular role. > > > > I think that anything that requires administrator activity to be a fail > for > > residential use. It's too complex. > > There will ALWAYS be a need for an administrator in the enterprise case. > But maybe with the options above we can ease the consumer burden over > time. In the consumer case, you might want an app for initial device > admission control anyway, no? Can we not rely on that interaction as an > approval step in this instance? > > > > >> To make that declaration, the device must- Form the declaration; Find > >> the MUD manager; and Send it. > > > >> Finding the MUD manager depends on one question: Was the device built > >> to be a controller or is it a general purpose device that has an app > >> that is intended to be a controller? > > > >> If the device was built to be a controller, we can simply cram the > >> declaration into that devices own MUD file as an extension. If the > >> device is a general purpose computer, things get a bit more > >> interesting. > More precisely if the application that wants to declare itself to be a controller is running on a general purpose controller then things could become interesting. > > > Yes... but I think that we have to solve the multi-purpose computer MUD > > anyway. The intelligent speakers (Echo,Home,Mycroft,etc.) need to gain > new > > MUD definitions as they gain "skills", and I think that we can treat a > > smartphone in a similar way. > It's a chicken and egg problem but I think we need to see some further adoption before throwing such complications into the mix. > > > This might be a place where IPv6 wins, if we can split off each skill > into a > > new provisioning domain, giving it a new IPv6 IID. I was thinking that > maybe > > we can associate the private key that signed the MUD file to the IID vi= a > > something like SEND/CGA, but I'm not sure how many private keys we have > > (one for the app developer, or one per app installed on each device). > > > > > >> In this case we have two choices: > > > >> Either create a MUD file that points somewhere internally - this > >> doesn=E2=80=99t seem very plug and play. Make the declaration directl= y to the > >> MUD manager. > > > >> I=E2=80=99m going to focus on the latter for the moment. It is easy e= nough to > >> create a RESTful interface for this purpose, but it requires a > >> mechanism to discovered the MUD manager, which up until now has been a= n > >> internal part of the network infrastructure. > > > >> Let me call this out plainly: letting the app itself directly call the > >> MUD manager requires that the MUD manager itself become exposed to the > >> user infrastructure, which is a change. > > > > Agreed. > > And that the MUD manager have some reason to trust the device is not > p0wned, > > and sending a bogus MUD file up. A certificate chain back to the > > manufacturer is not enough, it has to be signed by a key that an attack= er > > can't get access to. So that requires attested keys if they are > "local", or > > for the signature to be done elsewhere. > > > >> One possibility to address this is to incorporate the new RESTful > >> endpoint into an ANIMA BRSKI join registrar, which may already be > >> exposed. But that requires that ANIMA BRSKI be in play, which it may > >> not. > I think the simplest approach would be to define a REST interface to the mud controller. This can be invoked by the join registrar (in case brski is being used) so that it is not directly exposed. When a controller (which could be an application) is admitted to the network, the join registrar signals the MUD manager. Thus the MUD manager does not need exposure in case brski is being used. In case brski is not being used, exposure (or limited exposure) may not be avoidable. How to discover the MUD manager (i.e. where it is running the API server) in case brski is not being used? Not clear, but won't simple direct configuration do the trick? Alternatively there are many discovery protocols (some better than others). So long as the application declaring itself to be the controller can be trusted, I don't see a big problem with exposing a RESTful API. Yes you now have an API that can be invoked by anyone who can access the MUD manager. How do you authenticate the invoker of this API? Again - many answers possible. A simple one -- it must present a trusted certificate signed by a trusted authority (verified using a certificate chain and yes key exposure is a known risk but isn't that always the case for public key encryption?). There application itself must be trustworthy but that can be verified by checking its code signature manually or automatically while installing it. So while not perfect I think it is a reasonable solution. Just my 2c. > > > > It is, however, a really good idea for the case where it is in play. > > > >> My thinking is that we do this work in two stages. First handle the > >> easy case, which is the MUD file extension, and then figure out how to > >> do the app version of this. > > > >> Thoughts? > > > > yes. > > > > Was that =E2=80=9Cyes=E2=80=9D to the two stage approach? > > Eliot > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > > > > > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > --=20 M. Ranganathan --00000000000065a6c9058c3ad84d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 26, 2019 at 6:56 AM Eliot= Lear <lear@cisco.com> wrote:


> On 25 Jun 2019, at 21:52, Michael Richardson <mcr+ietf@sandelman.ca> wrote= :
>
> Signed PGP part
>
> Eliot Lear <lea= r@cisco.com> wrote:
>> A few of us are just trying to put out an initial draft that addre= sses
>> one gap in MUD (there are several).
>
>> In a MUD file one can say that one
>> wants to access a controller in two ways: either "my-controll= er=E2=80=9D
>> meaning a controller that services devices of a particular MUD URL= or a
>> =E2=80=9Ccontroller=E2=80=9D class that services devices based on = a particular class
>> name of controller.
>
> I think that we have two potential avenues for security attacks here:<= br> >=C2=A0 1) a device that claims to be a controller in order to gain acce= ss to
>=C2=A0 =C2=A0 =C2=A0devices.
>=C2=A0 2) devices that claim to be belong to a controller in order to a= ttack
>=C2=A0 =C2=A0 =C2=A0controllers.
>
> To my mind there are some different things we could do:
>
> 1) insist that to user the my-controller connections that the two devi= ces
>=C2=A0 =C2=A0have to be signed by the "same" entity.=C2=A0 [&= quot;same" could mean literal the
>=C2=A0 =C2=A0same key, the same certificate Issuer/DN,=C2=A0 or somethi= ng more complex]
>
> 2) we could have devices declare in an MUD extension the
>=C2=A0 =C2=A0DN/certificate/entity which must sign their controller dev= ice.

controller or my-controller could = refer to an application (not necessarily another device). However, the appr= oach you are suggesting could apply to an application as well.


>
> 3) (2) above, but with some level of indirection through some URL.


I could see these as options.

>
>> In either case, right now the administrator has to manually know a= nd
>> populate information, to say - some device 1.2.3.4 is a controller= ,
>> either for MUD URL https://example.com/mud <https://example.com= /mud> or
>> a class http://example.com/mudclass1 <http://example.= com/mudclass1>.
>> That can be laborious.=C2=A0 To assist, we are examining ways to h= ave a
>> controller declare itself as a candidate controller.=C2=A0 That at= least
>> provides a hint to the administrator that this particular device i= s
>> capable of serving in a particular role.
>
> I think that anything that requires administrator activity to be a fai= l for
> residential use.=C2=A0 It's too complex.

There will ALWAYS be a need for an administrator in the enterprise case.=C2= =A0 But maybe with the options above we can ease the consumer burden over t= ime.=C2=A0 In the consumer case, you might want an app for initial device a= dmission control anyway, no?=C2=A0 Can we not rely on that interaction as a= n approval step in this instance?

>
>> To make that declaration, the device must- Form the declaration; F= ind
>> the MUD manager; and Send it.
>
>> Finding the MUD manager depends on one question: Was the device bu= ilt
>> to be a controller or is it a general purpose device that has an a= pp
>> that is intended to be a controller?
>
>> If the device was built to be a controller, we can simply cram the=
>> declaration into that devices own MUD file as an extension.=C2=A0 = If the
>> device is a general purpose computer, things get a bit more
>> interesting.


Mo= re precisely if the application that wants to declare itself to be a contro= ller is running on a general purpose controller then things could become in= teresting.




>
> Yes... but I think that we have to solve the multi-purpose computer MU= D
> anyway.=C2=A0 The intelligent speakers (Echo,Home,Mycroft,etc.) need t= o gain new
> MUD definitions as they gain "skills", and I think that we c= an treat a
> smartphone in a similar way.


<= /div>
It's a chicken and egg problem but I think we need to see som= e further adoption before throwing such complications into the mix.


>
> This might be a place where IPv6 wins, if we can split off each skill = into a
> new provisioning domain, giving it a new IPv6 IID.=C2=A0 I was thinkin= g that maybe
> we can associate the private key that signed the MUD file to the IID v= ia
> something like SEND/CGA, but I'm not sure how many private keys we= have
> (one for the app developer, or one per app installed on each device).<= br>

>
>> In this case we have two choices:
>
>> Either create a MUD file that points somewhere internally - this >> doesn=E2=80=99t seem very plug and play.=C2=A0 Make the declaratio= n directly to the
>> MUD manager.
>
>> I=E2=80=99m going to focus on the latter for the moment.=C2=A0 It = is easy enough to
>> create a RESTful interface for this purpose, but it requires a
>> mechanism to discovered the MUD manager, which up until now has be= en an
>> internal part of the network infrastructure.
>
>> Let me call this out plainly: letting the app itself directly call= the
>> MUD manager requires that the MUD manager itself become exposed to= the
>> user infrastructure, which is a change.
>
> Agreed.
> And that the MUD manager have some reason to trust the device is not p= 0wned,
> and sending a bogus MUD file up.=C2=A0 =C2=A0A certificate chain back = to the
> manufacturer is not enough, it has to be signed by a key that an attac= ker
> can't get access to.=C2=A0 So that requires attested keys if they = are "local", or
> for the signature to be done elsewhere.
>
>> One possibility to address this is to incorporate the new RESTful<= br> >> endpoint into an ANIMA BRSKI join registrar, which may already be<= br> >> exposed.=C2=A0 But that requires that ANIMA BRSKI be in play, whic= h it may
>> not.


I thi= nk the simplest approach would be to define a REST interface=20 to the mud controller. This can be invoked by the join registrar (in=20 case brski is being used) so that it is not directly exposed. When a controller (which could be an application) is admitted to the=20 network, the join registrar signals the MUD manager.=C2=A0 Thus the MUD=20 manager does not need exposure in case brski is being used.

<= /div>
In case brski is not being used, exposure (or limited exposure) = may not be avoidable.

How to discover the MUD = manager (i.e. where it is running the API server) in case brski is not bein= g used? Not clear, but won't simple direct configuration do the trick?= =C2=A0 Alternatively there are many discovery protocols (some better than o= thers).

=C2=A0So long as the application decl= aring itself to be the controller can be trusted, I don't see a big pro= blem with exposing a RESTful API. Yes you now have an API that can be invok= ed by anyone who can access the MUD manager. How do you authenticate the in= voker of this API? Again - many answers possible. A simple one -- it must p= resent a trusted=C2=A0 certificate signed by a trusted authority (verified = using a certificate chain and yes key exposure is a known risk but isn'= t that always the case for public key encryption?). There application itsel= f must be trustworthy but that can be verified by checking its code signatu= re manually or automatically while installing it. So while not perfect I th= ink it is a reasonable solution.



Just my 2c.
=C2=A0
>
> It is, however, a really good idea for the case where it is in play. >
>> My thinking is that we do this work in two stages.=C2=A0 First han= dle the
>> easy case, which is the MUD file extension, and then figure out ho= w to
>> do the app version of this.
>
>> Thoughts?
>
> yes.
>

Was that =E2=80=9Cyes=E2=80=9D to the two stage approach?

Eliot

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>
>
>
>
>

--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud


--
M. Ranganathan

<= /div>
--00000000000065a6c9058c3ad84d-- From nobody Wed Jun 26 08:34:47 2019 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 F2C5D1201DC; Wed, 26 Jun 2019 08:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 SQhCHwJbzC17; Wed, 26 Jun 2019 08:34:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3958712014E; Wed, 26 Jun 2019 08:34:36 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 44EA838183; Wed, 26 Jun 2019 11:32:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BF5CFE68; Wed, 26 Jun 2019 11:34:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BD76FE37; Wed, 26 Jun 2019 11:34:35 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: opsawg@ietf.org, mud@ietf.org In-Reply-To: References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Declaring something to be a controller in MUD 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, 26 Jun 2019 15:34:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >>> In either case, right now the administrator has to manually know and >>> populate information, to say - some device 1.2.3.4 is a controller, >>> either for MUD URL https://example.com/mud or >>> a class http://example.com/mudclass1 . >>> That can be laborious. To assist, we are examining ways to have a >>> controller declare itself as a candidate controller. That at least >>> provides a hint to the administrator that this particular device is >>> capable of serving in a particular role. >> >> I think that anything that requires administrator activity to be a f= ail for >> residential use. It's too complex. > There will ALWAYS be a need for an administrator in the enterprise > case. But maybe with the options above we can ease the consumer burd= en > over time. In the consumer case, you might want an app for initial > device admission control anyway, no? Can we not rely on that > interaction as an approval step in this instance? I think we'd all like to have a generic app (with an RFC standard API) that can onboard any device and can do admission control for any controller. I think this is what you are saying as well. >>> One possibility to address this is to incorporate the new RESTful >>> endpoint into an ANIMA BRSKI join registrar, which may already be >>> exposed. But that requires that ANIMA BRSKI be in play, which it m= ay >>> not. >> It is, however, a really good idea for the case where it is in play. >> >>> My thinking is that we do this work in two stages. First handle the >>> easy case, which is the MUD file extension, and then figure out how= to >>> do the app version of this. >> >>> Thoughts? >> >> yes. >> > Was that =E2=80=9Cyes=E2=80=9D to the two stage approach? "Yes" :-) Eliot Lear wrote: >> 1) insist that to user the my-controller connections that the two de= vices >> have to be signed by the "same" entity. ["same" could mean literal = the >> same key, the same certificate Issuer/DN, or something more complex] >> >> 2) we could have devices declare in an MUD extension the >> DN/certificate/entity which must sign their controller device. >> >> 3) (2) above, but with some level of indirection through some URL. > Another thought here: > We could provide a level of dereference for authorized controllers in > the device=E2=80=99s MUD file, in the form of a URL list that would l= ook > something like: > { [ > =E2=80=9Ccontroller=E2=80=9D : =E2=80=9Ccontroller-name" > =E2=80=9Cmud-urls=E2=80=9D : [ some mud urls of valid controllers her= e ] > =E2=80=9Cinclude=E2=80=9D : =E2=80=9Chttps://levelofindirection.examp= le.com=E2=80=9D that points to a file that contains a JSON serialization of= this grouping > } yes, this is exactly what I was thinking about. Would "mud-urls" / "include" be mutually exclusive? =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0TkIsACgkQgItw+93Q 3WXw0Qf+OuxPT1S56UO/VtPTBkhiEFK9DsjPrNTjzPq/jzpa79iBqRoSe6Evf4bN HX9uggictVTtyIxjW9JE1nWaPP/FF4JK2JixZTTGt4+4+le7cZ7eHf1A8ph7Gw7L /Fe7i094NHgKME1yZsC9gSo8eyfiHpNDIYkrVX0AZcnaynvA6N0AohnjMnKTJeW8 ZgAU7I78myGClo1Et8cNLahQIWcBgTG+Gmldl9KKDvmc/VSTkFIes1FPyOENdR/i fUjSDDJYVMcOQpUAXTvwksg5eDqZEbgGph8aXYJHLy5DWSxcQfwvHpesDI2tJbn3 XJtLDedS+I2w1/lmjfwjuE/QIlmW4A== =4OTt -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 26 08:43:17 2019 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 A6F33120100; Wed, 26 Jun 2019 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, 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 mtmIJ2Ts9NWE; Wed, 26 Jun 2019 08:43:05 -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 1FC7612003E; Wed, 26 Jun 2019 08:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5110; q=dns/txt; s=iport; t=1561563785; x=1562773385; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ZQRBKeQzTVT9jnz3njd9giCaN/RSYI5YJxdHdpZmWLs=; b=dDcyXLryMRPmIAGQxK94OnRO6yU5jgLp6URJGltNVDMWtv8mVBnmBPgv xsxiZk/62V+5UkBy97KpaCDsjNCfyCss2yYsApwdAgBRbZnSqLXifP0ho SikUPWMAgwHNXu6yd+OFyimGWOF7ch/Sb3kacXKbko6ipAJetAeMGsnre g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAAC4kRNd/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4MBUQEyIQeEFYh7i18lmmcCBwEBAQkDAQEjDAEBgUuCdQK?= =?us-ascii?q?DIDgTAQMBAQQBAQIBBW2KNwyFSgEBAQMBI1EFBQsLGCoCAlcGE4MiAYF7Dwg?= =?us-ascii?q?HpWSBMYVHhF0QgTSBUYokgX+BOAwTgh4uPoJWhHgygiYEjAGHb1qVUAmCGII?= =?us-ascii?q?egQqDKI0fG4MWlD6UCFiBd4JTiA2DCQIEBgUCFYFnIYFYMxoIGxU7KgGCQQk?= =?us-ascii?q?1ggqDFVSKVT0DMI8rAQE?= X-IronPort-AV: E=Sophos;i="5.63,420,1557187200"; d="asc'?scan'208";a="13557855" 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; 26 Jun 2019 15:43:02 +0000 Received: from ams3-vpn-dhcp6365.cisco.com (ams3-vpn-dhcp6365.cisco.com [10.61.88.220]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QFh1PG003375 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jun 2019 15:43:02 GMT From: Eliot Lear Message-Id: <7DDDF804-8171-4E1E-91C5-CBE4D2965939@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_555F9A05-FBC8-4287-8E2B-E270949473E2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Jun 2019 17:43:00 +0200 In-Reply-To: <11505.1561563275@localhost> Cc: opsawg@ietf.org, mud@ietf.org To: Michael Richardson References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> <11505.1561563275@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.88.220, ams3-vpn-dhcp6365.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] [OPSAWG] Declaring something to be a controller in MUD 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, 26 Jun 2019 15:43:08 -0000 --Apple-Mail=_555F9A05-FBC8-4287-8E2B-E270949473E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Jun 2019, at 17:34, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Eliot Lear wrote: >>>> In either case, right now the administrator has to manually know = and >>>> populate information, to say - some device 1.2.3.4 is a controller, >>>> either for MUD URL https://example.com/mud = or >>>> a class http://example.com/mudclass1 = . >>>> That can be laborious. To assist, we are examining ways to have a >>>> controller declare itself as a candidate controller. That at least >>>> provides a hint to the administrator that this particular device is >>>> capable of serving in a particular role. >>>=20 >>> I think that anything that requires administrator activity to be a = fail for >>> residential use. It's too complex. >=20 >> There will ALWAYS be a need for an administrator in the enterprise >> case. But maybe with the options above we can ease the consumer = burden >> over time. In the consumer case, you might want an app for initial >> device admission control anyway, no? Can we not rely on that >> interaction as an approval step in this instance? >=20 > I think we'd all like to have a generic app (with an RFC standard API) = that > can onboard any device and can do admission control for any = controller. > I think this is what you are saying as well. Yes, but I was saying a bit more. Do you expect to fully automate the = inclusion of a controller into a controller class in the home? How do = you envision the full flow looking like? >=20 >>>> One possibility to address this is to incorporate the new RESTful >>>> endpoint into an ANIMA BRSKI join registrar, which may already be >>>> exposed. But that requires that ANIMA BRSKI be in play, which it = may >>>> not. >=20 >>> It is, however, a really good idea for the case where it is in play. >>>=20 >>>> My thinking is that we do this work in two stages. First handle = the >>>> easy case, which is the MUD file extension, and then figure out how = to >>>> do the app version of this. >>>=20 >>>> Thoughts? >>>=20 >>> yes. >>>=20 >=20 >> Was that =E2=80=9Cyes=E2=80=9D to the two stage approach? >=20 > "Yes" :-) Okidoke. >=20 > Eliot Lear wrote: >>> 1) insist that to user the my-controller connections that the two = devices >>> have to be signed by the "same" entity. ["same" could mean literal = the >>> same key, the same certificate Issuer/DN, or something more = complex] >>>=20 >>> 2) we could have devices declare in an MUD extension the >>> DN/certificate/entity which must sign their controller device. >>>=20 >>> 3) (2) above, but with some level of indirection through some URL. >=20 >> Another thought here: >=20 >> We could provide a level of dereference for authorized controllers in >> the device=E2=80=99s MUD file, in the form of a URL list that would = look >> something like: >=20 >> { [ >> =E2=80=9Ccontroller=E2=80=9D : =E2=80=9Ccontroller-name" >> =E2=80=9Cmud-urls=E2=80=9D : [ some mud urls of valid controllers = here ] >> =E2=80=9Cinclude=E2=80=9D : = =E2=80=9Chttps://levelofindirection.example.com=E2=80=9D that points to = a file that contains a JSON serialization of this grouping >> } >=20 > yes, this is exactly what I was thinking about. >=20 > Would "mud-urls" / "include" be mutually exclusive? I don=E2=80=99t see why it would have to be. But now let=E2=80=99s back = up, just to make sure we=E2=80=99re not digging too deep a hole for the = application case that Ranga wants to get to. If the MUD protected = device is declaring MUD URLs for MUD controllers and that is what all of = this would boil down to, then the app case is really a completely = separate mechanism, because apps don=E2=80=99t have MUD-URLs. If we do a two-stage, then we need a completely separate draft for apps = anyway, but I was hoping for some commonality. Eliot >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_555F9A05-FBC8-4287-8E2B-E270949473E2 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXROShAAKCRBugA9nE248 uB3cAJ4iy4c3tM2U4/Df7RTtiDShja/8aACgjEucxDe/aouMPByD8lY6M403r74= =a+ZV -----END PGP SIGNATURE----- --Apple-Mail=_555F9A05-FBC8-4287-8E2B-E270949473E2-- From nobody Wed Jun 26 14:26:36 2019 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 BE6FD120188; Wed, 26 Jun 2019 14:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 mHjcPmi4dHOw; Wed, 26 Jun 2019 14:26:28 -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 0C09E1203AE; Wed, 26 Jun 2019 14:26:27 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D9A13808A; Wed, 26 Jun 2019 17:24:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 297E2E68; Wed, 26 Jun 2019 17:26:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 28194E37; Wed, 26 Jun 2019 17:26:26 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: opsawg@ietf.org, mud@ietf.org In-Reply-To: <7DDDF804-8171-4E1E-91C5-CBE4D2965939@cisco.com> References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> <11505.1561563275@localhost> <7DDDF804-8171-4E1E-91C5-CBE4D2965939@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Declaring something to be a controller in MUD 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, 26 Jun 2019 21:26:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >>> There will ALWAYS be a need for an administrator in the enterprise >>> case. But maybe with the options above we can ease the consumer bu= rden >>> over time. In the consumer case, you might want an app for initial >>> device admission control anyway, no? Can we not rely on that >>> interaction as an approval step in this instance? >> >> I think we'd all like to have a generic app (with an RFC standard AP= I) that >> can onboard any device and can do admission control for any controll= er. >> I think this is what you are saying as well. > Yes, but I was saying a bit more. Do you expect to fully automate the > inclusion of a controller into a controller class in the home? How do > you envision the full flow looking like? I expect to fully automate the inclusion of a controller into that class, yes. I'd like to automate the device into the class too. Perhaps your point is that since the controller has to onboard (at the layer-7) the device in anyway: can we leverage that? >> yes, this is exactly what I was thinking about. >> >> Would "mud-urls" / "include" be mutually exclusive? > I don=E2=80=99t see why it would have to be. But now let=E2=80=99s b= ack up, just to > make sure we=E2=80=99re not digging too deep a hole for the applicati= on case > that Ranga wants to get to. If the MUD protected device is declaring > MUD URLs for MUD controllers and that is what all of this would boil > down to, then the app case is really a completely separate mechanism, > because apps don=E2=80=99t have MUD-URLs. > If we do a two-stage, then we need a completely separate draft for ap= ps > anyway, but I was hoping for some commonality. Hmm. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0T4wEACgkQgItw+93Q 3WWDzwf/bi6qFjt9u8BccDWI80xNHoHQrrA+4cZaLK+h4ROMpmD8yckfKspPZZU9 LZU4zJyJFE+yS/avjGLiRuiQ0WhH3YdQym0WZ/ujiqLgQzUmLqFbGOoJ0rDLl0Bx TeBYtPH1kcmdF/kLH/z9+8zVYvYztIIBHMlkrLswkY6GCK4U/JD+FD1m0aPCuLSD 0M5xJvZ8FnOo2nohFr9yqWIYW+3nrZ7ZSphWiwZWMoDFmbJTGYJORcZoyFTWR9X+ BQntrCLZJ8X8ewZ2gOou/SYYihEHhCZIsd7Cgm53P0Z2LbtfvasOJqlwRrPiTi0J YQwPjGnnuwtsGpH0fBDYK+davtVdBQ== =R92T -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 26 14:30:32 2019 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 5411B1202B4; Wed, 26 Jun 2019 14:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, 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 OxxQcRlwZV3w; Wed, 26 Jun 2019 14:30:29 -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 0CFE6120140; Wed, 26 Jun 2019 14:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2859; q=dns/txt; s=iport; t=1561584629; x=1562794229; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=kPpy6UQz0d7j6zfCtcWcdDmjJGd9A8GcejMWhFWcsTM=; b=HBp5nHzK7YVM4MR4DxfJqoX4yxUVo4NdfeFG0ZvtKqh0kh17jootripQ 07bDa54jtPOiO8lowv4z55dmbxiWd+RKcu8NWSj31Gfph2kpBnNZEl9aR x899PIzOMg2YTTHh4fnAUQlJ3XMzVtZSsOum/BiAMfZr15eCKTG7MmjHd 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAADF4hNd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBg1IyKIQViHuLYCWaZgIHAQEBCQMBAS8?= =?us-ascii?q?BAYRAAoMgNwYOAQMBAQQBAQIBBW2KQ4VKAQEBAwEjUQUFCwsYKgICVwYTgyI?= =?us-ascii?q?BgXsPpgKBMYVHhGMQgTQBgVCKJIF/gTgME4IeLj6HTjKCJgSUS5VRCYIYgh6?= =?us-ascii?q?BCpBIG5dVoTiDCQIEBgUCFYFmIoFYMxoIGxVlAYJBPoIKjj49AzCQAQEB?= X-IronPort-AV: E=Sophos;i="5.63,421,1557187200"; d="asc'?scan'208";a="13567216" 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 Jun 2019 21:30:26 +0000 Received: from ams3-vpn-dhcp6365.cisco.com (ams3-vpn-dhcp6365.cisco.com [10.61.88.220]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QLUPHS028501 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jun 2019 21:30:26 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1B2458D9-F3BD-4F70-8C2B-5FBF48A12F7E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Jun 2019 23:30:24 +0200 In-Reply-To: <13929.1561584386@localhost> Cc: opsawg@ietf.org, mud@ietf.org, "M. Ranganathan" To: Michael Richardson References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> <11505.1561563275@localhost> <7DDDF804-8171-4E1E-91C5-CBE4D2965939@cisco.com> <13929.1561584386@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.88.220, ams3-vpn-dhcp6365.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Mud] [OPSAWG] Declaring something to be a controller in MUD 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, 26 Jun 2019 21:30:31 -0000 --Apple-Mail=_1B2458D9-F3BD-4F70-8C2B-5FBF48A12F7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Jun 2019, at 23:26, Michael Richardson = wrote: >=20 >=20 > Eliot Lear wrote: >>>> There will ALWAYS be a need for an administrator in the enterprise >>>> case. But maybe with the options above we can ease the consumer = burden >>>> over time. In the consumer case, you might want an app for initial >>>> device admission control anyway, no? Can we not rely on that >>>> interaction as an approval step in this instance? >>>=20 >>> I think we'd all like to have a generic app (with an RFC standard = API) that >>> can onboard any device and can do admission control for any = controller. >>> I think this is what you are saying as well. >=20 >> Yes, but I was saying a bit more. Do you expect to fully automate = the >> inclusion of a controller into a controller class in the home? How = do >> you envision the full flow looking like? >=20 > I expect to fully automate the inclusion of a controller into that = class, > yes. I'd like to automate the device into the class too. >=20 > Perhaps your point is that since the controller has to onboard (at the > layer-7) the device in anyway: can we leverage that? For devices that are designed as controllers, yes. >=20 >>> yes, this is exactly what I was thinking about. >>>=20 >>> Would "mud-urls" / "include" be mutually exclusive? >=20 >> I don=E2=80=99t see why it would have to be. But now let=E2=80=99s = back up, just to >> make sure we=E2=80=99re not digging too deep a hole for the = application case >> that Ranga wants to get to. If the MUD protected device is declaring >> MUD URLs for MUD controllers and that is what all of this would boil >> down to, then the app case is really a completely separate mechanism, >> because apps don=E2=80=99t have MUD-URLs. >=20 >> If we do a two-stage, then we need a completely separate draft for = apps >> anyway, but I was hoping for some commonality. >=20 > Hmm. >=20 Indeed. But let=E2=80=99s not get wrapped around the axle here. I=E2=80=99= ll try and have something out for the controller case, and then let=E2=80=99= s talk about the other in Montreal. Ok? Eliot --Apple-Mail=_1B2458D9-F3BD-4F70-8C2B-5FBF48A12F7E 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXRPj8AAKCRBugA9nE248 uMrIAKDAvj4OjDz0TQUmjxCYdNRLlwc2IQCg8j+SB5U6LKFqQt8K//cwd0JcfQ0= =yswq -----END PGP SIGNATURE----- --Apple-Mail=_1B2458D9-F3BD-4F70-8C2B-5FBF48A12F7E-- From nobody Wed Jun 26 17:07:02 2019 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 A6EC7120314 for ; Wed, 26 Jun 2019 17:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fL6SzMbDAhdr for ; Wed, 26 Jun 2019 17:06:59 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 F207D1200B5 for ; Wed, 26 Jun 2019 17:06:58 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id u19so711468ior.9 for ; Wed, 26 Jun 2019 17:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hQKVfQ8Dz1hNmyXINFvq+xBkluaeyErw/KXuqI0XZSw=; b=PBEdIcgKhmj3O5BMoNgZmdSzEqewVv8DNXEStZq8bY3CXuM/d9COTKxGIPofG589XU JpB3dP/+O6aYrwQwN+0L/ghMpz6twrUpTtI6ydKAMhGt2REOiFHZrkbVlOIZnOX7OXuu aTLGLQIamJ6m/JFf6v8n1bImNKFGjcENnlBreM2b8CuwlCFy4WyvGxtv92gB2L/5yXl/ phCOjNzkzZ1p6ft1PPkbBSEANXzlBEEx8UBonjGiv10gUylg1La1FYIyMPgnPEv65+V8 R/llN0BmfBflrAvuB8wWCtVbKPJEzKqBgx647FdiL4cr22NJHBcWOpVPcxKkOWGdnc0d eb0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hQKVfQ8Dz1hNmyXINFvq+xBkluaeyErw/KXuqI0XZSw=; b=g7FLn004SMPeZO9plOvf33/p1qIhFmTDpz8ktXxkSkZiKDCLWMEBpIbiOE7WBc81+T ddQxWl5BsuVa5ygfQNxzdf+eSKht8Nk+ouH1PuYubL8YT/4Hrn6VHxuNYEuf5AwaziVM mbk6Pqc4HewFzwvwWvh9KfLMP14iSyw3nATR4L9uKrhzdp7gbx3m4zUB4QW9PvaAoZ6B UWAxOCqxIopq6YtZ1fiQiD7PkRWlaL7yHlC7gPRXb6ZNL/SLCqohVyaSpfaC1sh6+usF mSWRlyHV24zXkjdxfoTMCVuShVWNCBO/8sztJDS5uxGzMuCIhQJ/xkikP87H8eEWVbw2 3zfg== X-Gm-Message-State: APjAAAVDizphMw2WSsqDKLL8DkyAtj9yamshO5V1mYEf8P/GXzURb+TD O6+jfuRKwODBjOx0mzsw+++jtHTcc8AmBiFRu8y+ZngM X-Google-Smtp-Source: APXvYqym/QNGh2Z7PthAwCJjTzIRD1KkSEQy7fkcgFzmX5lAYJS5TZH3GpdO430M/T7X1SRB+EYZ/Ktejx7aWhQuWQw= X-Received: by 2002:a05:6602:2252:: with SMTP id o18mr1049662ioo.63.1561594017757; Wed, 26 Jun 2019 17:06:57 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Wed, 26 Jun 2019 20:06:21 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000b63c3c058c42f061" Archived-At: Subject: [Mud] Basic questions about the "Controller" abstraction. 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, 27 Jun 2019 00:07:01 -0000 --000000000000b63c3c058c42f061 Content-Type: text/plain; charset="UTF-8" Hello all, In another thread we've been discussing declaring devices that are "controllers" of other devices via extensions to MUD whereby we specify the MUD URIs of controllers for a given device. We've gone rather deep into the possible mechanisms to achieve this but I still have some basic questions which I hope Eliot can help me with. Indeed, MUD already provides the model abstraction. So one could define an ACE using that abstraction. Why bother with the "controller" abstraction which one later binds to a MUD URI rather than just directly use the "model" abstraction in the ACE in case one would like to control a device with another device. What is the essential difference? I hope my question is clear. Am I missing something? Thanks, Regards, Ranga -- M. Ranganathan --000000000000b63c3c058c42f061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

In another thread= we've been discussing declaring devices that are "controllers&quo= t; of other devices via extensions to MUD whereby we specify the MUD URIs o= f controllers for a given device. We've gone rather deep into the possi= ble mechanisms to achieve this but I still have some basic questions which = I hope Eliot can help me with.

=C2=A0Indeed, M= UD already provides the model abstraction. So one could define an ACE using= that abstraction. Why bother with the "controller" abstraction w= hich one later binds to a MUD URI rather than just directly use the "m= odel" abstraction in the ACE in case one would like to control a devic= e with another device.

What is the essential diffe= rence?

I hope my question is clear.
<= div>
Am I missing something?=C2=A0

T= hanks,

Regards,

Ranga
=

--
M. Ranganathan =

<= /div>
--000000000000b63c3c058c42f061-- From nobody Sun Jun 30 01:54:59 2019 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 83E34120077; Sun, 30 Jun 2019 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 INSXc_V52ZPz; Sun, 30 Jun 2019 01:54:48 -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 DAE42120071; Sun, 30 Jun 2019 01:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1739; q=dns/txt; s=iport; t=1561884888; x=1563094488; h=from:mime-version:subject:message-id:date:to; bh=nd2QLKHla1fgRdOsaMoPo7RwUojmPIeDBxuc4nJbDdk=; b=dbNFpHzot3Vg3aTMQKAZE8HyfmeyPGggB8TxU+QAXncU9CMffrUgH79E v/0Y9MxKSp8GVrSAHFNfuvlHEBckIp47I95/gbtagcSe66JOllHlvqjlJ gtXfuBma5eEmdQWlQrfWlL0C+e5obC7rFLZyoSRkVhZP5lh8RZNGbKfew E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAABGeBhd/xbLJq1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAUBAQELAYNRIRKERYh7pHqBewIHAQEBCQMBAS8BAYdlNQgOAQM?= =?us-ascii?q?BAQQBAQIBBW2KQ4VuBoEzAmAmgw4BggqkLYEyijMQgTQBgVCKJYF/gTgfgh6?= =?us-ascii?q?IOjKCJgSUV5VYCYIYA4IcgQuQUBQHjSuKPoQRiR+UGoMJAgQGBQIVgVEBNoF?= =?us-ascii?q?YMxoIGxVlAYJCPZBJPQOQCgEB?= X-IronPort-AV: E=Sophos;i="5.63,434,1557187200"; d="asc'?scan'208";a="13704388" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jun 2019 08:54:46 +0000 Received: from [10.61.213.67] ([10.61.213.67]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5U8sjwx005178 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 30 Jun 2019 08:54:45 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_BE15E828-8DBE-4430-B896-1826252809D5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sun, 30 Jun 2019 10:54:43 +0200 To: mud@ietf.org, iot-onboarding@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.213.67, [10.61.213.67] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Mud] Side meeting at the IETF Montreal - call for agenda items 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: Sun, 30 Jun 2019 08:54:51 -0000 --Apple-Mail=_BE15E828-8DBE-4430-B896-1826252809D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With the release of the meeting agenda we are now able to book side = meetings. A number of people have contacted me about meeting in Montreal, and that = they wouldn=E2=80=99t be available after Tuesday. Conveniently, Monday = morning is reserved for side meetings. I propose we take advantage of = this from 9:00 - 10:30 (yes, this bleeds into the 1st session). I=E2=80=99ve combined MUD and IoT Onboarding, just to save time, as = there is substantial community overlap. That=E2=80=99s because the = spaces are clearly related, one being authentication of the device the = other being network authorization. This, then, is a call for agenda items. I have a few of my own, but = would prefer to hear from others first. Also, are you ok with the = Monday morning time slot and keeping these activities together? Eliot Ps: reminder: side meetings are not =E2=80=9Cofficial=E2=80=9D anything. = Just a gathering of people with a common interest. However, the = meeting will run under the IPR rules of the IETF, regardless. All are = invited. --Apple-Mail=_BE15E828-8DBE-4430-B896-1826252809D5 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXRh40wAKCRBugA9nE248 uFbbAKCVksUyvom7WmL9zUcnXqgNDfEAUwCfTBcZLG0lXO94mMLvn1Kz+TzjtgA= =4Gir -----END PGP SIGNATURE----- --Apple-Mail=_BE15E828-8DBE-4430-B896-1826252809D5-- From nobody Sun Jun 30 01:56:07 2019 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 6FC4A120073; Sun, 30 Jun 2019 01:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 38l54WOHSLA3; Sun, 30 Jun 2019 01:55:56 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21603120071; Sun, 30 Jun 2019 01:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1943; q=dns/txt; s=iport; t=1561884956; x=1563094556; h=from:mime-version:subject:date:references:to:in-reply-to: message-id; bh=Wltlu14UAkTewz/b0GqqOep+pFJUt4eLpTKM8EHs4ZY=; b=jClNSdBpBGWg4tjv0NcJl+jn7KSME6RKseDA5egiZbkmOj2r6SGVC+0J Fq4tZ5DnN2ML6l9T/0zXVyf8c9/uQOjHYsQHz9TOqDW9wUWCcbbCC5ZyL m7nJNwNv1OnzM59cXKFkQUYNHuK/7cGTHkrg3dXvMfJDVwWJrqqUer1S/ Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABGeBhd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBg1EhEiiEHYgcX4wImHKBewIHAQEBCQM?= =?us-ascii?q?BAS8BAYRAAoMjNAkOAQMBAQQBAQIBBW2KQ4VKAQEBAwEdBlsLCxgqAgJXBxI?= =?us-ascii?q?Ugw4BgXsPpC2BMoozEIE0AYFQiiWBf4E4H4IeLj6HTjKCJgSUV5VYCYIYgh+?= =?us-ascii?q?BC5BQG40rij6EEYkflBqDCQIEBgUCFYFQOIFYMxoIGxVlAYJBPpBJPQMwj1o?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.63,434,1557187200"; d="asc'?scan'208";a="13763466" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jun 2019 08:55:53 +0000 Received: from [10.61.213.67] ([10.61.213.67]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x5U8trUF010995 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 30 Jun 2019 08:55:53 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_5BDD09E4-54C1-4E4C-AD18-0418A81F693E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 30 Jun 2019 10:55:52 +0200 References: To: mud@ietf.org, iot-onboarding@ietf.org In-Reply-To: Message-Id: <44D33562-AA85-423E-B69D-15FC35F69F12@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.213.67, [10.61.213.67] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Mud] [Iot-onboarding] Side meeting at the IETF Montreal - call for agenda items 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: Sun, 30 Jun 2019 08:55:59 -0000 --Apple-Mail=_5BDD09E4-54C1-4E4C-AD18-0418A81F693E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The meeting will be in C2 on the 21st floor. A U-shaped room. > On 30 Jun 2019, at 10:54, Eliot Lear wrote: >=20 > Signed PGP part > With the release of the meeting agenda we are now able to book side = meetings. >=20 > A number of people have contacted me about meeting in Montreal, and = that they wouldn=E2=80=99t be available after Tuesday. Conveniently, = Monday morning is reserved for side meetings. I propose we take = advantage of this from 9:00 - 10:30 (yes, this bleeds into the 1st = session). >=20 > I=E2=80=99ve combined MUD and IoT Onboarding, just to save time, as = there is substantial community overlap. That=E2=80=99s because the = spaces are clearly related, one being authentication of the device the = other being network authorization. >=20 > This, then, is a call for agenda items. I have a few of my own, but = would prefer to hear from others first. Also, are you ok with the = Monday morning time slot and keeping these activities together? >=20 > Eliot > Ps: reminder: side meetings are not =E2=80=9Cofficial=E2=80=9D = anything. Just a gathering of people with a common interest. However, = the meeting will run under the IPR rules of the IETF, regardless. All = are invited. >=20 >=20 >=20 --Apple-Mail=_5BDD09E4-54C1-4E4C-AD18-0418A81F693E 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXRh5GAAKCRBugA9nE248 uA8vAKDfgltG6MYTLuCxVlrpV7MaKtiNVwCeJlHLzThL+FZBevIrzihqGWva+J0= =xMqA -----END PGP SIGNATURE----- --Apple-Mail=_5BDD09E4-54C1-4E4C-AD18-0418A81F693E-- From nobody Sun Jun 30 09:49:47 2019 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 BCC4D12015E; Sun, 30 Jun 2019 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 dUPmgMjA4w7W; Sun, 30 Jun 2019 09:49:44 -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 8784112015D; Sun, 30 Jun 2019 09:49:40 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 85AC43818C; Sun, 30 Jun 2019 12:47:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C9C67D53; Sun, 30 Jun 2019 12:49:38 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: mud@ietf.org, iot-onboarding@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Side meeting at the IETF Montreal - call for agenda items 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: Sun, 30 Jun 2019 16:49:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > A number of people have contacted me about meeting in Montreal, and > that they wouldn=E2=80=99t be available after Tuesday. Conveniently,= Monday > morning is reserved for side meetings. I propose we take advantage of > this from 9:00 - 10:30 (yes, this bleeds into the 1st session). It bleeds into teep, and I'm curious about the loops BOF, so I probably take off at the appointed time. > I=E2=80=99ve combined MUD and IoT Onboarding, just to save time, as t= here is > substantial community overlap. That=E2=80=99s because the spaces are= clearly > related, one being authentication of the device the other being netwo= rk > authorization. Agreed. > This, then, is a call for agenda items. I have a few of my own, but > would prefer to hear from others first. Also, are you ok with the > Monday morning time slot and keeping these activities together? > Ps: reminder: side meetings are not =E2=80=9Cofficial=E2=80=9D anythi= ng. Just a > gathering of people with a common interest. However, the meeting will > run under the IPR rules of the IETF, regardless. All are invited. So, I'm not sure if you are asking for BRSKI items, or IoT onboarding items= in general. 1) Under BRSKI for non-ANIMA ACP uses, there is the question about open/clo= sed registrars, and operational considerations of total sales channel integr= ation (MASA knows the customers), vs retail integration (no knowledge of customers). There are probably areas of grey in between that might be worth enumerating. 2) There is a similar question for MUD, which is how does the MUD controller arrive at trust criteria for the signatures. This is the enterprise/customer side of the above story: do you know who you are buying from? This relates to the discussion we have had about controllers: I think if we could pin down the quality of the signatures, we could say more. 3) MUD Operational considerations for devices that can grow "skills" Not really a topic exactly: but how do we get towards the point where we ca= n test MUD/BRSKI integration. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0Y6CIACgkQgItw+93Q 3WWBaAgAgLjOaPSxi9sRlUJ/BMyxlXL6ZFcWVQbQIIUOViCr8rDj5zgbT+2ky4wU mgBNfUBQBpZGk5I6fKbRVOm/8DM2Jigp2gBjmCF0ejXMFxyNq/NSpu/WFgLzmfBD KWcHuIIj3rKMlP5GJKUWyJkoMvIJOnF+ih1ajPO6p9wzbMj24GoT3QIUCr58ebtM 83kBOQwUHWKdWPMzDGOy8qLSLsKNOXBd/ByQVIpgcyv+AycAsP4FjwYRhgJpyJvI LE8a/6RW/tFg5GitspLjMHoplquukKXGW1vtsg7/f7JYSIgrnOnKY9USY+zPkX3k VxmhJTr5bEp3PF5FHfsJCZCv6KzyeA== =g+oy -----END PGP SIGNATURE----- --=-=-=--