From nobody Thu Aug 1 07:45:44 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 053FA120020; Thu, 1 Aug 2019 07:45:42 -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 piYwYcTrjAPY; Thu, 1 Aug 2019 07:45:40 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 EB37A12000E; Thu, 1 Aug 2019 07:45:39 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id i10so31579480iol.13; Thu, 01 Aug 2019 07:45:39 -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=QjLGrYzK6H/yrV3cEQuS2ed9RpeL5roU/g4XdhaYkUA=; b=cYzz99GI3HRn9PnRjSbm8yB8HzbrKeDMmuidJk5qwBXczhE62EoXILYtsrVsGhpIOx rJiP/JUWhPvQjA3hyCz/RUe35FdD1c6uAyDnTZlOzWG+OoVfatZ0AglrlQPHmzcSQJCS qU4SxxQ3CqDVLczA+/gNX/n+j06QqWJJxuivfuOWR5zw1dWM+Iz23fc4e0jYRfTMXdFl OZLXtUdfLuEGU4q/Pk40SbCNG4B28DKRynxM+n/WW4pm+n67IECwKYzTGAcmzc6hATu4 QxCxEqkc1yzcJb3MBGPUhnU21V8D+SAqdwzjQs72ECsL/qB8djck0bEwVJDezn3L1ojT 1/Gw== 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=QjLGrYzK6H/yrV3cEQuS2ed9RpeL5roU/g4XdhaYkUA=; b=c7f2qdh/2xe8pgxHyf28FhEViBk+eIQ7cnWdDmfOAO5yYBcjVrE1gAXyDDNs1yQBtv ViqjJFYrq0Tu/UNyr/OQIgL4vT5qig6YAaMDXi98zP8x7/RATC3VNa7WPhmvsDuHPr38 CIxEA7tVkWWnU5tYdhaNkm7ve34NJGOe/8w5vHk9nRt5Ss0iZcjmPO4GKo+eOhBLtq0w M9cQMOrVaBR4y8bL9LyNai4MqFIyev6NKjGn6GfviZiy9mtfY00Vo0BJ/fqSTUDAxr63 VdtJWo+YqIJBY3//YqG0xwke8fjbYMtkJwcrflWEFfx74FaBqiTg6YrMEWwqIpJZZrQo Pqww== X-Gm-Message-State: APjAAAXzu8ua49W5GYa57Ub7F6XSKewj8mYQKYZAuhl9HM/XURlvnNVP PYroF0UrRAMvqaL/vBCBTWNlyXivqe0rJ4wHiGs= X-Google-Smtp-Source: APXvYqzZL1tvllIC9yfvA6Uk50GCd2wBTYunRyDf4PkKoHU+OmC5t/B7pwwGcs1WadEtvltbPUAYaDWkW2PaMJbvct8= X-Received: by 2002:a05:6638:5:: with SMTP id z5mr18120754jao.58.1564670739012; Thu, 01 Aug 2019 07:45:39 -0700 (PDT) MIME-Version: 1.0 References: <849DED7F-6701-4B26-9645-0B076A224C05@cisco.com> In-Reply-To: From: tirumal reddy Date: Thu, 1 Aug 2019 20:15:27 +0530 Message-ID: To: Eliot Lear Cc: "Joe Clarke (jclarke)" , "opsawg@ietf.org" , "ops-ads@ietf.org" , mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000096dfe2058f0f4be6" Archived-At: Subject: Re: [Mud] [OPSAWG] The future of MUD 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: Thu, 01 Aug 2019 14:45:42 -0000 --00000000000096dfe2058f0f4be6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A new WG to focus on MUD sounds like a good idea. Several vendors and ISPs offer security services to protect home networks, protecting IoT devices in home networks is one of the key challenges, and MUD can help secure IoT devices in both Enterprise and home networks and the security solutions in both these networks are quite different. Cheers, -Tiru On Wed, 31 Jul 2019 at 14:15, Eliot Lear wrote: > On the other hand, it shouldn=E2=80=99t just be me. It=E2=80=99d be a ve= ry small working > group ;-) If others are interested, they should speak up. > > On 30 Jul 2019, at 11:09, Eliot Lear wrote: > > Signed PGP part > Hi Joe, > > On 29 Jul 2019, at 23:44, Joe Clarke (jclarke) wrote: > > OpsAWG members and our Ops ADs, it was discussed in opsawg at IETF 105 > that with the amount of MUD work being proposed (and discussions happenin= g > outside of opsawg) that perhaps MUD should evolve into its own WG. Some > cons to this approached were discussed (maybe it would be too heavy-weigh= t > with a charter, milestones, etc.). However, I wanted to take this > conversation to the list so we can close on it publicly. > > Speaking as WG co-chair, I am happy to continue to support the MUD work i= n > opsawg, but I want to make sure the WG feels compelled to work on it; and= I > want to make sure the full community that is interested in MUD can follow > and discuss items here. That said, it was mentioned in 105 that perhaps = a > bigger =E2=80=9Con-boarding=E2=80=9D set of work would be better served i= n its own WG. I > think if the scope of MUD grows beyond the definition and its extensions > (as we=E2=80=99ve been seeing the work progress thus far) it might be bet= ter served > in its own WG space. > > Thoughts? > > > I think it is probably time for at least one WG to spring from OPSAWG. W= e > didn=E2=80=99t really complete the agenda at the IETF, and a good reason = of that > was MUD. There are at least four active drafts on that one subject, one = of > which we didn=E2=80=99t really talk about (bw-profile). For me it=E2=80= =99s a matter of > what can reasonably be coded, tested, and be useful for manufacturers. I= n > as much as we can bring a bit more focus to manufacturers by offering the= m > more of a venue for discussion, the additional WG would be welcome. On t= he > other hand, if we find that we=E2=80=99re not making progress, or if we p= rogress > extensions quickly, we can close the WG and continue the mailing list, an= d > move back to OPSAWG. I don=E2=80=99t see a MUD working group as a long t= erm > activity (famous last words), but targeted more at producing the necessar= y > for broader adoption and then going out of business. > > Eliot > > > Joe > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --00000000000096dfe2058f0f4be6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A new WG to focus on MUD sounds like a good idea. Sev= eral vendors and ISPs offer security services to protect home networks, pro= tecting IoT devices in home networks is one of the key challenges, and MUD = can help secure IoT devices in both Enterprise and home networks and the se= curity solutions in both these networks are quite different.=C2=A0

Cheers,
-Tiru

On Wed, 31 Jul 2019 at 1= 4:15, Eliot Lear <lear@cisco.com&g= t; wrote:
On the other hand, it shouldn=E2=80=99t= just be me.=C2=A0 It=E2=80=99d be a very small working group ;-) If others= are interested, they should speak up.

On 30 Jul 2019, at 11:09, Eliot Lear <lear@cisco.com> wrote:

Signed PGP part
Hi Joe,

On 29 Jul 2019, at 23:44, Joe Clarke (jclarke) <jclarke@cisco.com> wrot= e:

OpsAWG members and our Ops ADs, it was discussed in opsawg at IET= F 105 that with the amount of MUD work being proposed (and discussions happ= ening outside of opsawg) that perhaps MUD should evolve into its own WG.=C2= =A0 Some cons to this approached were discussed (maybe it would be too heav= y-weight with a charter, milestones, etc.).=C2=A0 However, I wanted to take= this conversation to the list so we can close on it publicly.

Speak= ing as WG co-chair, I am happy to continue to support the MUD work in opsaw= g, but I want to make sure the WG feels compelled to work on it; and I want= to make sure the full community that is interested in MUD can follow and d= iscuss items here.=C2=A0 That said, it was mentioned in 105 that perhaps a = bigger =E2=80=9Con-boarding=E2=80=9D set of work would be better served in = its own WG.=C2=A0 I think if the scope of MUD grows beyond the definition a= nd its extensions (as we=E2=80=99ve been seeing the work progress thus far)= it might be better served in its own WG space.

Thoughts?

I think it is probably time for at least one WG to spring from OP= SAWG.=C2=A0 We didn=E2=80=99t really complete the agenda at the IETF, and a= good reason of that was MUD.=C2=A0 There are at least four active drafts o= n that one subject, one of which we didn=E2=80=99t really talk about (bw-pr= ofile).=C2=A0 For me it=E2=80=99s a matter of what can reasonably be coded,= tested, and be useful for manufacturers.=C2=A0 In as much as we can bring = a bit more focus to manufacturers by offering them more of a venue for disc= ussion, the additional WG would be welcome.=C2=A0 On the other hand, if we = find that we=E2=80=99re not making progress, or if we progress extensions q= uickly, we can close the WG and continue the mailing list, and move back to= OPSAWG.=C2=A0 I don=E2=80=99t see a MUD working group as a long term activ= ity (famous last words), but targeted more at producing the necessary for b= roader adoption and then going out of business.

Eliot


Joe
_____________________________________________= __
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg<= /a>



<= br>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
--00000000000096dfe2058f0f4be6-- From nobody Thu Aug 1 13:45: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 0710112022B; Thu, 1 Aug 2019 13:45:57 -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 cZdYSwDBkmIR; Thu, 1 Aug 2019 13:45:54 -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 90CEA1201BB; Thu, 1 Aug 2019 13:45:54 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C8C9380BE; Thu, 1 Aug 2019 16:45:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5FF7D8EF; Thu, 1 Aug 2019 16:45:52 -0400 (EDT) From: Michael Richardson To: "opsawg\@ietf.org" , mud@ietf.org, "ops-ads\@ietf.org" In-Reply-To: References: <849DED7F-6701-4B26-9645-0B076A224C05@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] The future of MUD 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: Thu, 01 Aug 2019 20:45:57 -0000 --=-=-= Content-Type: text/plain This is my list of MUD work. This is what I'm already active in, or which I expect to start documents soon. I have not included documents that others are writing! 1) title: Manufacturer Usuage Description for quarantined access to firmware docname: draft-richardson-shg-mud-quarantined-access-00 2) title: A standard process to quarantine and restore IoT Devices docname: draft-richardson-shg-un-quarantine-01 NOTE: I expect this document to go through RIPE IoT WG. I expect this document to provide a GAP ANALYSIS 3) title: MUD processing and extensions for Secure Home Gateway Project docname: draft-richardson-opsawg-securehomegateway-mud-00 Informational document, may not need to be published. 4) Operational considerations for using DNS names and IP literals in IoT devices (planned. Not sure how to fit MUD into the title yet, but this is driven my the constrained that MUD needs) -> will need to reference draft-reddy-dprive-bootstrap-dns-server which we hope to get into DPRIVE WG soon. -> but otherwise, it's a BCP that will emphasis certain things that BEHAVE probably started. 5) (planned) CAPPORT extensions for signaling quarantine status to IoT devices 6) (planned) A profile of IPFIX to carry anonymized telemetry from MUD controllers to Network Operators. [there was also discussion about sending it to manufacturers] [this grows out of {2}] ==== Other NON-MUD related IoT work that I see/have started ==== 7) draft-ietf-6tisch-dtsecurity-zero-touch could be without a WG if 6tisch shuts down very soon. 8) (planned) BRSKI adaptions for use with Cloud Registrars [may instead be a profile of RFC8572] [this grows out of ACME-integration discussion, btw] 9) Extensions to BRSKI to carry device/firmware attestion artifacts(claims) {clearly, I can't do all of these things alone} -- ] 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 [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1DT4AACgkQgItw+93Q 3WVpJQgAvSSAgObvix1A7Nb3k6StCUWBxesMVVhDKbw3NeTr4NgGfcvtfupHdi40 bsTUeoob30BLXaPfHk9KsJ9FKDzpEtSEQhLVesbtbWC/SLsmFXUWNoxoAQCEBNUb 9jUFryQsavO8fJZSrh/bzc1rG0T9VelV24YAcIlPgVtAflzoSkmYHRNWXF/1ra6x pm29WbzjERXsfCg+9K4VwooYp6kn0UA58xWUo6DEfHHZShOgfg+wz66ZBXikm6FQ A68Bc3ed4OlroJGLBBTQPnoxos3yh9X1O/dSbvidJ8DKFbogldpFbb36mJjGxpOM jJww5iSeKEmK5wbWA4GTyyVK/fhnrg== =Hnw6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 1 14:12:09 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 95048120128; Thu, 1 Aug 2019 14:12:07 -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 QUi88-mxjbtt; Thu, 1 Aug 2019 14:12:05 -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 271031200F7; Thu, 1 Aug 2019 14:12:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E57A23818D; Thu, 1 Aug 2019 17:11:35 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9EE9680; Thu, 1 Aug 2019 17:12:03 -0400 (EDT) From: Michael Richardson To: iot-wg@ripe.net, opsawg@ietf.org cc: mud@ietf.org In-Reply-To: References: <12332.1564605651@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: [Mud] extending/amending IPFIX for MUD unquarantine 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: Thu, 01 Aug 2019 21:12:08 -0000 --=-=-= Content-Type: text/plain I want to introduce the IETF OPSAWG to some MUD related work that I started in the spring. After some discussion about an appropriate place for this work, I realized that this is primarily aimed at Operators, and I primarily want feedback from those who want to do this. I also realized in March that was I was building a playbook, and that the IETF CACAO (BOF) work might want to use some of this as requirements, but that BOF didn't continue. So the plan is to do this mostly in the RIPE IoT-WG, with the document providing recommendations (BCP), and also gap analysis feedback to many places, including the IETF. The talk I was going to do at RIPE78 did not happen due to a short agenda. I had done a screencast; it got cut off 94% through due to a full /var/tmp, but I decided that was good enough. The slides and video are below. My thanks to Kathleen Moriarty who walked me through some of the ROLIE/STIIX/MISP stuff that I know very little about. The first step of the Secure Home Gateway/MUD-Controller to ISP/operator link is when an IoT device violates it's MUD profile. My document contemplates two stages of pergatory on the assumption that MUD ACLs will initially be not that reliable, and what we do not want to do is to train end users to click through warnings. This requires some kind of "three strikes" and you are out kind of system, and to make that work, well, to continue the Baseball analogy, we need an umpire. The ISP/network-operator will need to do that, and that means that they need to get data on what is going wrong. Which devices are doing what, and how often, and this needs to be in enough detail to corelate across customers. And the data needs to be pseudo-nonymized and expunged against the eventual database breach or LEA action. IPFIX seems to be the right protocol for this. Tiru says they already use it. It will need some significant extra security/management layer to provide for automatic enrollment. Also needed is some kind of feedback to the MUD controller as to how significant this event currently is, and whether futher quarantine is waranted or whether to expect an updated MUD file. It has been suggested that this part of the first step is a place for DOTS. The document is in your nearest Internet Draft archive as: draft-richardson-shg-un-quarantine-00 and the github is at: https://github.com/CIRALabs/shg-un-quarantine including the slides in fodp and pdf format (with the animations expanded) in the "presentations" folder. The screencast/video is at: http://junk.sandelman.ca/junk/unquarantine-RIPE-talk.ogv https://youtu.be/GOmHx8jpaCM -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1DVaMACgkQgItw+93Q 3WVJLgf+MAJE7ogDnq/sklO7khFgEkUajgXE/MeNGiwLDTbmQDYbhYNzyWO5P9lo uU32pWQrrjM7iTng0yvzEXGvLP07wir0HJhRWI4X2sEcQf/ILQcP6HPiyPPXmvwQ AsPlVElFtbtD0Du7rIJiRpxo5piOHrN8oeTovZGiWYsHcOQCq4e7rmAJOwI6Psm+ yVNyxYdw1aCXKMnqBIVR2RKXzcTqsWsbSNBUc8aHjpAd0gwBNRb9mFyuVElygxEp 8mmqA7Nq+Y/z5srrPhiPI7pvusjlE8mM+YOjIE0eHUSTb8Vxlqt78kX32IkUVCwk EFhVAQfF3znNPSOmTn3OOC4Qe31XYw== =7NOp -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 9 08:05:12 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 931BB12007A for ; Fri, 9 Aug 2019 08:05:10 -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 vvmt4izmmjuM for ; Fri, 9 Aug 2019 08:05:08 -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 73E6B12012D for ; Fri, 9 Aug 2019 08:05:08 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A9C23818F for ; Fri, 9 Aug 2019 11:04:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3D1AC5BE for ; Fri, 9 Aug 2019 11:05:06 -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] [Add] Chromecast using 8.8.8.8 (fwd) Paul Hoffman: [Add] Chromecast using 8.8.8.8 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, 09 Aug 2019 15:05:11 -0000 --=-=-= Content-Type: text/plain It would be interesting to have MUD file for the Chromecast. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=364 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by localhost with IMAP (fetchmail-6.3.26) for (single-drop); Fri, 09 Aug 2019 10:51:11 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus git2.4.17+0-Debian-2.4.17+nocaldav-0+deb8u2) with LMTPA; Thu, 08 Aug 2019 22:03:13 -0400 X-Sieve: CMU Sieve 2.4 Received: from delivery.mtaroutes.com (delivery.mtaroutes.com [185.201.18.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id 0294E3818D for ; Thu, 8 Aug 2019 22:03:13 -0400 (EDT) Received: from mail.ietf.org ([4.31.198.44]) by mx126.antispamcloud.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1hvuFy-000qqb-KH for mcr+ietf@sandelman.ca; Fri, 09 Aug 2019 04:03:51 +0200 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F15E81200FD for ; Thu, 8 Aug 2019 19:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1565316229; bh=dXevNdy6NCwITjGbPP6ghTVRdg+/Z62NUqh/Qk4OEWo=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=b3aPt2YZNoQrKriVtFA3vVprJ9ES60NYXjhlQ64qToM7CrSXTK62aiGvaiTtoYqbM 9NMSY/BoAbGna2Hm6vWDZhOy+rSoOOaGzZuf4iMSrxsJXNaLBpJtJLBHTWfvOj0q4T dRyZphKiB52HNmVYsoOOHefFx/SB1yIyCU2J4kY8= X-Mailbox-Line: From add-bounces@ietf.org Thu Aug 8 19:03:48 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADA412002F; Thu, 8 Aug 2019 19:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1565316228; bh=dXevNdy6NCwITjGbPP6ghTVRdg+/Z62NUqh/Qk4OEWo=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=JY3A17aMh2ist4XroEbdaqnsfAEBVNLY1myS6fRWKvGIhzpDLOKFUwPRHypfctjYx c0XYn1Z7dIx11tvf9uA2iCZ+uwcj0AkOp13HO33CK/AKQibaSziM2q1sQKQFVnSZX0 hHLr8k6dXDtygQfscZAFMDG6QR1QndU0vMeEHMmM= X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723F812006A for ; Thu, 8 Aug 2019 19:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwl8tjk0_TVH for ; Thu, 8 Aug 2019 19:03:45 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5441512002F for ; Thu, 8 Aug 2019 19:03:45 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 19:03:43 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1473.005; Thu, 8 Aug 2019 19:03:43 -0700 From: Paul Hoffman To: ADD Mailing list Thread-Topic: Chromecast using 8.8.8.8 Thread-Index: AQHVTlary1EUTWy3tkmOV4cCRz/KQg== Date: Fri, 9 Aug 2019 02:03:42 +0000 Message-ID: <474778E2-BC34-4D87-951E-9CA2174F4F77@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-ID: MIME-Version: 1.0 Archived-At: Subject: [Add] Chromecast using 8.8.8.8 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: add-bounces@ietf.org Sender: "Add" Received-SPF: pass (mx126.antispamcloud.com: domain of ietf.org designates 4.31.198.44 as permitted sender) client-ip=4.31.198.44; envelope-from=add-bounces@ietf.org; helo=mail.ietf.org; X-SPF-Result: mx126.antispamcloud.com: domain of ietf.org designates 4.31.198.44 as permitted sender Authentication-Results: mx126.antispamcloud.com; dmarc=none header.from=icann.org Authentication-Results: antispamcloud.com; spf=pass smtp.mailfrom=add-bounces@ietf.org; dkim=pass header.i=ietf.org X-Filter-Label: newsletter X-MailAssure-Class: whitelisted X-MailAssure-Evidence: sender X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0YiRRkpbHZ8F3zevhEShTfypSDasLI4SayDByyq9LIhVRJKuoL20070G U5Ufdh+41WqUuh2MpmQbQvmrab9RbAHqH6xvmyo++UsFY6JUjVh4shsxya8iQXED5vSUQ++rDser 6nXFRBneIuQ/tHetyAi9h4ByECSYb5zgaPyMu0AnWmuNA8WTybi1JN85FSnfKfltWGvLbCuZaQoe 5UGcu4B41pf+MEiJXhuIeYzeKNTzkVWClPVvbW5lVyQanRxw5nmS7Qi4DDvwnPe/m0ZwJguF4MXC BjASdP/gQilaCwuE7H2ZC56yr6xDfRL3L1neeyODJgPrCtC9pJVsir/Bwp2kDci70QkCOxa9CI+8 v8i3KLTFpngmCzMfOMV6XuhaoY5WQalhwZktt5CZh2miEJOYgisbzJ0S6rR70RDllHBX8K+I8p+Q na8XwVJgUE8fgT3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpAA1m6zMBZL/nitqfxQqB rXwCY8vmv+JqOVJamBHfOGXHHVx5mFXlUdMlhfvLRMZjuvExD7f6C2dHfLRhGXswyPE8b6CLjusa z22hMkFhvN90DAR32uxK0sKi0q2H6tLFTCAAaaqkRisg7PMbozN3KkHtvkLsnbI3mpzo+bJxKrqj kzeDp3yO9aUV/bh87oOirM34stdmjiUXCe8axo5Al/QD2d0jJX+zqj7M72yx2ma3AHNWiybFOZmN WNJ/NeyhxjnI8mwlsL5v9PnJbVLQo55hPdMqkcXNbCZCMXXGUnDSxK7BT9xBZOKDwev+Dfm/UV8S hebT8U8Xw9HTDfreWfBXKHhP/bkmKFsOzFSaKkbDqcigOvSxdRnthmhn8Zn6Do/N7ZLb2zzB/II8 ANmMUANW7/99Dy9nHLy5ZjpT/CPB9dQUyNMfYPIPyLmQ7ltmVgW9/bktU41htiJ8fk7NkM23J7LH DHZzGBAiCeuHbrg= X-Report-Abuse-To: spam@quarantine10.antispamcloud.com Greetings again. Earlier on the list, it was discussed that Google's Chromecast device uses 8.8.8.8 for DNS service regardless of the settings that were provided by DHCP from the wireless access point. I bought a new one and captured the DNS traffic, and that statement is oddly approximately half-true. For every DNS lookup, the Chromecast sends the the same query to 8.8.8.8 *and* the resolver that it was given by DHCP. A popular way to control a Chromecast is with the GoogleHome application on a phone. On my iPhone on the same wireless access point, GoogleHome always used the resolver from DHCP. Note that GoogleHome gave the Wifi password to the Chromecast during setup, so it could have passed other settings like the resolver address, but appears not to have. The Chromecast's use of 8.8.8.8 continued after setup and reboot, so it was not just a fluke of the setup process. There is no way in GoogleHome that I could find to set the network settings for the Chromecast other than to change the wireless access point. (The tinkerer in me was tempted to set up a resolver that sometime changes the addresses it sends out and see what the Chromecast does with the differing information, but that's beyond the scope of this problem.) For comparison, I installed a new Amazon Firestick, and all DNS went to the resolver configured from DHCP. I'm not sure how to categorize the Chromecast's odd behavior, but it certainly is sending queries to a DNS resolver that is not expected by the network administrator. I'd be interested to hear from folks on this list if they know of other devices or applications that by default hard-code a different resolver address than the one that comes from the operating system (for applications) or DHCP (for devices). --Paul Hoffman -- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add --=-=-=-- From nobody Thu Aug 15 17:54: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 D3AE5120103 for ; Thu, 15 Aug 2019 17:54:24 -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 EEUZH2y3UPWH for ; Thu, 15 Aug 2019 17:54:22 -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 838451200F3 for ; Thu, 15 Aug 2019 17:54:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A1E8E3818C for ; Thu, 15 Aug 2019 20:53:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 52346788 for ; Thu, 15 Aug 2019 20:54:21 -0400 (EDT) From: Michael Richardson To: mud@ietf.org In-Reply-To: <156262380876.734.2268328972581793672.idtracker@ietfa.amsl.com> References: <156262380876.734.2268328972581793672.idtracker@ietfa.amsl.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: [Mud] draft-richardson-opsawg-mud-iot-dns-considerations-00 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, 16 Aug 2019 00:54:25 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I started a document just before the IETF105 cut-off https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-iot-dns-co= nsiderations/ the intention of which is to address how IoT devices use DNS.=20=20 It's very drafty :-) I actually started the document again on Tuesday, forgetting where I'd place the first copy, and in it I used the term "specific purpose devices" rather than the more marketing "IoT" term. I don't want to fill in the solution part of the document yet, I'd prefer to make sure that I get the problem statement in the Introduction correct. Section 2: map names should deal with the different ways to map names using Do53. Section 3: should deal with pathologies that we see. For instance, using redirects to random CDN hostnames for access to firmware. Although I think that maybe these two sections along with part of the Intro should be in a Problem Statement section. Have I missed anything in the problem statement? How much introduction is in order so that DNS/DPRIVE and CDN types will understand this. 1. Introduction [RFC8520] provides a standardized way to describe how a specific purpose device makes use of Internet resources. Access Control Lists (ACLs) can be defined in an RFC8520 Manufacturer Usage Description (MUD) file that permit a device to access Internet resources by DNS name. Use of a DNS name rather than IP address in the ACL has many advantages: not only does the layer of indirection permit the mapping of name to IP address to be changed over time, it also generalizes automatically to IPv4 and IPv6 addresses, as well as permitting loading balancing of traffic by many different common ways, including geography. At the MUD policy enforcement point - the firewall - there is a problem. The firewall has only access to the layer-3 headers of the packet. This includes the source and destination IP address, and if not encrypted by IPsec, the destination UDP or TCP port number present in the transport header. The DNS name is not present! In order to implement this, there must be a mapping between the names in the ACLs and layer-3 IP addresses. The first section of this document details a few strategies that are used. The second section of this document details how common manufacturer anti-patterns get in the way this mapping. The third section of this document details how current trends in DNS resolution such as public DNS servers, DNS over TLS (DoT), and DNS over HTTPS (DoH) cause problems for the strategies employed. Poor interactions with content-distribution networks is a frequent pathology that results. The fourth section of this document makes a series of recommendations ("best current practices") for manufacturers on how to use DNS, and IP addresses with specific purpose IoT devices. The Privacy Considerations section concerns itself with issues that DNS-over-TLS and DNS-over-HTTPS are frequently used to deal with. The question is how these concerns apply to IoT devices located within a residence or enterprise is dealt with. The Security Considerations section covers some of the negative outcomes should MUD/firewall managers and IoT manufacturers choose not to cooperate. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1V/r0ACgkQgItw+93Q 3WUlPwf+O/m+X5Tns7yUDRxWNy2e5APVW1jDEz1f9sTRUivUuAB1RzQKKIMjIFkF VPbilHT455uBVBW4oPxTx6bCc2lvzYfGINn8hX8ykbW7hLvxoKVP1CGoASWWvkzp 100mUR9mmVVS0pJJW36ESxDwNm/K43SSAdz2tqUCNS7BitWN2CHBp5k2iaU83s1y gOiCkgtZBLmDUMpf+rIrNXWbBtdzKp2BZyoLSHp2faaZqkX/QJD8QVphVSBgyj0W jU+XOXUTX2VgXDFyiDmHRyG+j5BOtMneK6W9fP/UiFemSoGD8tnnbqBW4G58WSth LuLAzKR+sn+/g7axlANhk+CCV+Awjw== =QeYI -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 19 05:02: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 84A6F120019; Mon, 19 Aug 2019 05:02:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoR1GV9slJlf; Mon, 19 Aug 2019 05:02:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24842120013; Mon, 19 Aug 2019 05:02:21 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8DEFFF1E4D4DBB50A6FF; Mon, 19 Aug 2019 13:02:17 +0100 (IST) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 19 Aug 2019 13:02:16 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.9]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0439.000; Mon, 19 Aug 2019 20:02:12 +0800 From: Qin Wu To: Ted Lemon , Eliot Lear CC: "opsawg@ietf.org" , "mud@ietf.org" , "ops-ads@ietf.org" Thread-Topic: [OPSAWG] [Mud] The future of MUD work Thread-Index: AdVWhefvA5Ppb7FfT4GD4tFfpUDzUQ== Date: Mon, 19 Aug 2019 12:02:12 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA92A70B2dggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Mud] [OPSAWG] The future of MUD 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: Mon, 19 Aug 2019 12:02:24 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA92A70B2dggeml511mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx0aG91Z2ggSSBoYXZlbuKAmXQgYmVlbiBmb2xsb3dpbmcgdGhpcyB3b3JrIGNsb3NlbHksIEkg YmVsaWV2ZSBNVUQgaGFzIHNvbWUgdmVyeSBpbnRlcmVzdGluZyB1c2UgY2FzZXMsIGFuZCBJIGhv cGUgdGhhdCB3b3JrIGNvbnRpbnVlcy4gSSBhZ3JlZSB3aXRoIEVsaW90IHRoYXQgYSB3b3JraW5n IGdyb3VwIG11c3QgaGF2ZSBhIGNyaXRpY2FsIG1hc3Mgb2YgcGVvcGxlIHdpbGxpbmcgdG8gZG8g dGhlIHdvcmssIG5vdCBqdXN0IHNob3cgdXAgYXQgdGhlIG1lZXRpbmdzLiBJIGFsc28gdGhpbmsg dGhhdCBvbmNlIHRoZXJlIGFyZSBtb3JlIHRoYW4gdHdvIG9yIHRocmVlIGRyYWZ0cywgb24gYSB0 b3BpYyB3ZSBzaG91bGQgbW92ZSBpdCBvdXQgb2YgT1BTQVdHLCBzbyBNVUQgaXMgYSBnb29kIGNh bmRpZGF0ZSBmb3IgYSBuZXcgV0cuDQoNCi1RaW4NCuWPkeS7tuS6ujogT1BTQVdHIFttYWlsdG86 b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBUZWQgTGVtb24NCuWPkemAgeaXtumXtDog MjAxOeW5tDfmnIgzMeaXpSAxODoxNQ0K5pS25Lu25Lq6OiBFbGlvdCBMZWFyIDxsZWFyQGNpc2Nv LmNvbT4NCuaKhOmAgTogb3BzYXdnQGlldGYub3JnOyBtdWRAaWV0Zi5vcmc7IG9wcy1hZHNAaWV0 Zi5vcmcNCuS4u+mimDogUmU6IFtPUFNBV0ddIFtNdWRdIFRoZSBmdXR1cmUgb2YgTVVEIHdvcmsN Cg0KT24gSnVsIDMxLCAyMDE5LCBhdCA0OjQ1IEFNLCBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNv bTxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToNCk9uIHRoZSBvdGhlciBoYW5kLCBpdCBz aG91bGRu4oCZdCBqdXN0IGJlIG1lLiAgSXTigJlkIGJlIGEgdmVyeSBzbWFsbCB3b3JraW5nIGdy b3VwIDstKSBJZiBvdGhlcnMgYXJlIGludGVyZXN0ZWQsIHRoZXkgc2hvdWxkIHNwZWFrIHVwLg0K DQpJIGRvbuKAmXQgdGhpbmsgSSB3b3VsZCBuZWNlc3NhcmlseSBpbml0aWF0ZSB3b3JrLCBidXQg SSBzdXNwZWN0IGlmIHRoZXJlIHdlcmUgYSBNVUQgV0cgSSB3b3VsZCBzaG93IHVwIGZvciBpdCBh bmQgcmV2aWV3IGRvY3VtZW50cy4gIFRoZSBmYWN0IHRoYXQgTVVEIGlzIGluIE9QU0FXRyBoYXMg bWVhbnQgdGhhdCBJIGRvbuKAmXQgZ28gYmVjYXVzZSB0aGF04oCZcyBub3QgYSBXRyBJIG5vcm1h bGx5IGdvIHRvLCBhbmQgSSBkaWRu4oCZdCByZWFsaXplIHRoYXQgd2FzIHdoZXJlIHRoZSBNVUQg d29yayB3YXMgaGFwcGVuaW5nLg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABAA92A70B2dggeml511mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAy IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFu b3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFs dGhvdWdoIEkgaGF2ZW7igJl0IGJlZW4gZm9sbG93aW5nIHRoaXMgd29yayBjbG9zZWx5LCBJIGJl bGlldmUgTVVEIGhhcyBzb21lIHZlcnkgaW50ZXJlc3RpbmcgdXNlIGNhc2VzLCBhbmQgSSBob3Bl IHRoYXQgd29yayBjb250aW51ZXMuDQogSSBhZ3JlZSB3aXRoIEVsaW90IHRoYXQgYSB3b3JraW5n IGdyb3VwIG11c3QgaGF2ZSBhIGNyaXRpY2FsIG1hc3Mgb2YgcGVvcGxlIHdpbGxpbmcgdG8gZG8g dGhlIHdvcmssIG5vdCBqdXN0IHNob3cgdXAgYXQgdGhlIG1lZXRpbmdzLiBJIGFsc28gdGhpbmsg dGhhdCBvbmNlIHRoZXJlIGFyZSBtb3JlIHRoYW4gdHdvIG9yIHRocmVlIGRyYWZ0cywgb24gYSB0 b3BpYyB3ZSBzaG91bGQgbW92ZSBpdCBvdXQgb2YgT1BTQVdHLCBzbyBNVUQgaXMgYSBnb29kDQog Y2FuZGlkYXRlIGZvciBhIG5ldyBXRy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi1RaW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmIj4gT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmIj5UZWQgTGVtb248YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWYiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMjAxOTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZiI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjc8L3NwYW4+5pyIPHNwYW4gbGFu Zz0iRU4tVVMiPjMxPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAxODoxNTxicj4NCjwv c3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBFbGlvdCBMZWFyICZsdDtsZWFyQGNpc2NvLmNvbSZndDs8YnI+DQo8L3NwYW4+ PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gb3BzYXdnQGlldGYub3JnOyBtdWRAaWV0Zi5vcmc7IG9wcy1hZHNAaWV0Zi5vcmc8YnI+DQo8 L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gUmU6IFtPUFNBV0ddIFtNdWRdIFRoZSBmdXR1cmUgb2YgTVVEIHdvcms8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gSnVsIDMxLCAyMDE5LCBhdCA0 OjQ1IEFNLCBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20iPmxl YXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+T24gdGhlIG90aGVyIGhhbmQsIGl0IHNob3VsZG7igJl0IGp1c3QgYmUgbWUuICZuYnNw O0l04oCZZCBiZSBhIHZlcnkgc21hbGwgd29ya2luZyBncm91cCA7LSkgSWYgb3RoZXJzIGFyZSBp bnRlcmVzdGVkLCB0aGV5IHNob3VsZCBzcGVhayB1cC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIGRvbuKAmXQgdGhpbmsgSSB3b3VsZCBuZWNlc3NhcmlseSBpbml0aWF0ZSB3b3JrLCBidXQg SSBzdXNwZWN0IGlmIHRoZXJlIHdlcmUgYSBNVUQgV0cgSSB3b3VsZCBzaG93IHVwIGZvciBpdCBh bmQgcmV2aWV3IGRvY3VtZW50cy4gJm5ic3A7VGhlIGZhY3QgdGhhdCBNVUQgaXMgaW4gT1BTQVdH IGhhcyBtZWFudCB0aGF0IEkgZG9u4oCZdCBnbyBiZWNhdXNlIHRoYXTigJlzIG5vdCBhIFdHIEkg bm9ybWFsbHkNCiBnbyB0bywgYW5kIEkgZGlkbuKAmXQgcmVhbGl6ZSB0aGF0IHdhcyB3aGVyZSB0 aGUgTVVEIHdvcmsgd2FzIGhhcHBlbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABAA92A70B2dggeml511mbxchi_-- From nobody Thu Aug 22 14:22: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 0F30A120C5B for ; Thu, 22 Aug 2019 14:22:11 -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 mcNgNuQMynyG for ; Thu, 22 Aug 2019 14:22:09 -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 DF6ED120C5D for ; Thu, 22 Aug 2019 14:22:08 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id j5so15087046ioj.8 for ; Thu, 22 Aug 2019 14:22:08 -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=c8PIB7gT7Yf76VkCzdJQTX3uvo9cl8J19lv9BTF4fCg=; b=l7VV9Tf6iGRNkkbfA0rJ7YRQqaZ5gyy0/6c1/sai1zrPtxSz7bQQWBEnkxEjaImZ+T 4gZI302TOaWhNkdHw89ghJUZMVzlgF/YJgWrRLgiQoxCNXUR8JKfkrbOrR4AcCpsIEgY yyVOIekv1eRKfKX4vdt1pL9UEegYwOng/WQlkEyyvRppM/Gr2QFH5FCX5npDV97vSrYs ZT2vS5YZ95Vof6ZYIYiS+NHX7uGUmvuVR38RbWRnG5bDIzIBkjmvGpHKnfeZ41sd+uKQ 1Dy0LqpeCE8/FXV9rNVuFtxdhzExVkm80CIH7Mig4j+ZPyYQs2A8hhJkIlqwr4+6xbcE UR7g== 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=c8PIB7gT7Yf76VkCzdJQTX3uvo9cl8J19lv9BTF4fCg=; b=lxlR9G/v5RGIRbQS69+l7iLnw+u/D9Gf4gg/M4x7ZS7I6al7faGD4M7dgQTqlDV3e9 TEON+9vKHFRj3/MRIN+VNC2bzZWAzDdSjTrRvDbDgDwjhbg4Wb63W4i2YkSM8Louy+lY XH8yL7tip9EV/KGpJmZFnDVPtgZROv19Wgfb/mkqrOjuzADmZiNnBQLI44MaOMIirCcq l2zWTelCjpzZ4JQomlOBEmuBccQt15Q4rszuzTuixM9dyyXVupjDnbOHQAZ7DWv2Z/7n gJ0GeB+FK9CdmstUEsfI+PmgvuQTOc5Kl8qEqL5Ffr09MKh0GsbuIpRg1CWHJsR9DT5h E6Rg== X-Gm-Message-State: APjAAAXhNbvjChNbaXnxOpXMTkxH63IuKAtF5fWob+clHhcvzrGuOqVD YFt8+XsLYkjLyDX5FkJF2wuxsoctpgB3mzClKic1aSK6 X-Google-Smtp-Source: APXvYqyOilTeLYnjOTcVYRf95p1b4hjzzsQi2KTVw390Fl0rkfBJiO08wRtBEWVSG1ADcO7t7ov09zhJ+Q+yEOYwM5Q= X-Received: by 2002:a5e:9818:: with SMTP id s24mr2534736ioj.0.1566508927549; Thu, 22 Aug 2019 14:22:07 -0700 (PDT) MIME-Version: 1.0 From: "M. Ranganathan" Date: Thu, 22 Aug 2019 17:21:31 -0400 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a0f2e0590bb4851" Archived-At: Subject: [Mud] Different ways of declaring MUD URLs 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, 22 Aug 2019 21:22:15 -0000 --0000000000002a0f2e0590bb4851 Content-Type: text/plain; charset="UTF-8" The MUD spec discusses three ways in which a device may declare its MUD URL: - LLDP - 802.1AR certificate based. - DHCP What if there is a conflict? Should the MUD server keep the first association or last? -- M. Ranganathan --0000000000002a0f2e0590bb4851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The MUD spec discusses three ways in which a device m= ay declare its MUD URL:
- LLDP
- 802.1AR certificate ba= sed.
- DHCP

What if there is a conflict?= Should the MUD server keep the first association or last?

--=
<= div dir=3D"ltr">
M. Ranganathan

--0000000000002a0f2e0590bb4851-- From nobody Fri Aug 23 08:08: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 B8338120046 for ; Fri, 23 Aug 2019 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXEFFb6y8Q7m for ; Fri, 23 Aug 2019 08:08:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE98120074 for ; Fri, 23 Aug 2019 08:08:25 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [142.169.78.41]) by relay.sandelman.ca (Postfix) with ESMTPS id DBC7A1F45E; Fri, 23 Aug 2019 15:08:23 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C2B7A3FB5; Fri, 23 Aug 2019 11:08:48 -0400 (EDT) From: Michael Richardson To: "M. Ranganathan" cc: mud@ietf.org In-reply-to: References: Comments: In-reply-to "M. Ranganathan" message dated "Thu, 22 Aug 2019 17:21:31 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 23 Aug 2019 11:08:48 -0400 Message-ID: <19984.1566572928@dooku.sandelman.ca> Archived-At: Subject: Re: [Mud] Different ways of declaring MUD URLs 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, 23 Aug 2019 15:08:28 -0000 --=-=-= Content-Type: text/plain M. Ranganathan wrote: > The MUD spec discusses three ways in which a device may declare its MUD URL: > - LLDP > - 802.1AR certificate based. > - DHCP > What if there is a conflict? Should the MUD server keep the first association > or last? You mean, what if they don't point to the same URL? If so, I'd put the device into qurarantine immediately, as something is amiss. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1gAYAACgkQlUzhVv38 QpD1qAf+PUOAf0Yj2JihPaqBFIqhzWnai62pWdM4jPGPb/wMB7MNbOyHWqY1cKQ/ RFBfn1h7hs+hvYA5RZhvpjMYAb9QvOHiZQ9PqMaviNYmW8jaLCxDOhM9gq5yNwCV ZToYM/a4hAwyUeVyAfHJ9dqJ9i1oJtcGZSNgGCmpnjj9GIVhDRhcWBsOf+1cQ/EO HWLVML15+ihXv4idA/423shpROdWrw6oj2SIisVdtc1mtSXfU80ZghzejpA9X8v4 FmDTqDS8iH2xU/1rkcW5GlHhuLA/p31h+X1izNqyBYh1ZhpFNXlidpOD+eaynikF 6Pl70BJ67Rp9QLSl+QNWbOJw/9gZLw== =cWWn -----END PGP SIGNATURE----- --=-=-=--