From nobody Sat May 11 18:17:45 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 2FB27120160 for ; Sat, 11 May 2019 17:49:49 -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_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 DTtYtJR4HAiE for ; Sat, 11 May 2019 17:49:47 -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 F234412014B for ; Sat, 11 May 2019 17:49:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2564038286; Sat, 11 May 2019 20:42:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9CD2D10EE; Sat, 11 May 2019 19:51:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1DE911057; Sat, 11 May 2019 19:51:08 -0400 (EDT) From: Michael Richardson To: mud@ietf.org, mud-discuss@googlegroups.com reply-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: X-Mailman-Approved-At: Sat, 11 May 2019 18:17:44 -0700 Subject: [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: Sun, 12 May 2019 00:49:54 -0000 --=-=-= Content-Type: text/plain {did the list transition go as intended?} What should a MUD-manager do if a MUD file can no longer be found at the provided URL? Perhaps this is equivalent to the signature not verifying. I'm thinking specifically of a case where a device is initially created by a contractor, they dutifully create a MUD file, provide it to the customer to host, and then.. the customer forgets... marketing reorganizes the web site, etc. and so the MUD file goes missing. 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. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzXX+sACgkQgItw+93Q 3WV47gf+NHC/cx6BnxbGT96yTAYw1uIC7/Q/9ED7jNJ4dUWpksN7H7SBw87HE4HD uGy8ueXWDg3Hi2C0CjWbt4oHjWb1wC/WzeoKnBtyJHJDmiRDG89vnqR9C8yA0Hmu BmsEqC8BdN8cdyG7heHGd2ODdckaU1DhStrCgKwr68HMrCjiBo3WHQlJhhc7zkYh GZ1lHXYl6csd0qARSJjhEnS413BRzBJICLhEe7oMipwKCYgbQfhh4J/1YGCn8B2r jwdxFyi/313sq8UjEgrdssp1/gxLYK+KJJF04ZYoofn7ZQAaS2brAbqzJm8wY1HU l198ZWtWFGh8Ed+cHVCU2ZEoXowCMw== =UUhN -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat May 11 18:19: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 8393E1200FA for ; Sat, 11 May 2019 18:19:19 -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 (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 zf1f29bFERHg for ; Sat, 11 May 2019 18:19:17 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 2195F120092 for ; Sat, 11 May 2019 18:19:17 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id d13so3843758qth.5 for ; Sat, 11 May 2019 18:19:17 -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; bh=UdwAYH3dWz3mUzDIJv/DvACZyYdUKncVY13Tw1iZ1sE=; b=zlOag2uTeGRznBOkqHY6BUJtSJPF+bAsnP6uIoEGJcUBpt0xKTF1VzEX360ziDgSW5 ANX4C9KICZRS9LK16HQ7gwiIJGc7Ogo2OWMgf2bxOGxRuoRMwcyPwsInQqlvaPUx8Bkj BESTk30umXxNYrrIrDK4IOaFWm7n2cbVMN2OILhyRZw3fktbYMur8Qt6fIfN1/UCdfZo 8udRqf1DH6gTHqkAcisSByvvbwfJFpnhowWf0Q6Pnl07pdKPp5WAL5hoIu5uz7IIc7MU aR7owUoG9pJYSDCra48aafF9S1Hqo5CAxDbiggd9njZBlarYsBg+HiefYQpxqjSN7oIa NKKg== 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; bh=UdwAYH3dWz3mUzDIJv/DvACZyYdUKncVY13Tw1iZ1sE=; b=nO0f00Ydy84jY0qQSTq6NJBD5aq6PJt4CgOkjhJwmUeNuYcicSKXEE1YqGsxoE2Rw/ emt5WG272Cm3yVs6QE/BQwOutFW4LuM4Dg/ouwB5trHxS02v3EShi7WtEddb/gPXK0RL X9eXmkSaqXN9fmdexizBNqcJuYsZUz4UzJPMGYp+9EgcJ/dA5c+uBRmAU5BoHOUmyNTt rU27j3k1ltRckrpe/ENh6Mh2EwIZw+cWFJNykFHUdOTqAuFFSh/XxMa1a77OgfWzmUqe uVE/XJtNqbJhjg8v7vCFxjQQPpPliFkCnVIesjvzpY3TI2dEBKtB11O5CH1/5j53g2Dj HK6g== X-Gm-Message-State: APjAAAVZ4ZT+nwtIfHwq6iT3cKWhLGdp2VYHEhRN+imhE+Kya48910al 6BtVJnTs5GYallLDj30NRMnRLv0LBD31ZA== X-Google-Smtp-Source: APXvYqzueNodVqtXF9sYeFrOI4csGwh4h5/xrR9uTV1di/cRVYDJ+WQRGtnlN2A3qP5fQiOSGif+XQ== X-Received: by 2002:aed:3598:: with SMTP id c24mr17415296qte.364.1557623955913; Sat, 11 May 2019 18:19:15 -0700 (PDT) Received: from [206.123.31.196] (modemcable040.161-162-184.mc.videotron.ca. [184.162.161.40]) by smtp.gmail.com with ESMTPSA id p6sm4945477qkc.13.2019.05.11.18.19.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 May 2019 18:19:14 -0700 (PDT) From: "Marc Blanchet" To: mud@ietf.org Cc: mud-discuss@googlegroups.com Date: Sat, 11 May 2019 21:19:12 -0400 X-Mailer: MailMate (1.12.5r5632) Message-ID: In-Reply-To: <17454.1557618668@localhost> References: <17454.1557618668@localhost> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown 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: Sun, 12 May 2019 01:19:19 -0000 On 11 May 2019, at 19:51, Michael Richardson wrote: > {did the list transition go as intended?} sorry. just did. > > What should a MUD-manager do if a MUD file can no longer be found at > the > provided URL? Perhaps this is equivalent to the signature not > verifying. > > I'm thinking specifically of a case where a device is initially > created by a > contractor, they dutifully create a MUD file, provide it to the > customer to > host, and then.. the customer forgets... marketing reorganizes the web > site, > etc. and so the MUD file goes missing. > > 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. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- > You received this message because you are subscribed to the Google > Groups "mud-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to mud-discuss+unsubscribe@googlegroups.com. > To post to this group, send email to mud-discuss@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/mud-discuss/17454.1557618668%40localhost. > For more options, visit https://groups.google.com/d/optout. From nobody Tue May 14 04:31:57 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 EC03A1200A4 for ; Tue, 14 May 2019 04:31:54 -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 0foSKnjTZ8WL for ; Tue, 14 May 2019 04:31:53 -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 AFB8212006B for ; Tue, 14 May 2019 04:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2845; q=dns/txt; s=iport; t=1557833512; x=1559043112; h=from:mime-version:subject:date:references:to:in-reply-to: message-id; bh=qJ1ia+iTv9EqrQWCwTlZKu+YRc7bx56gBvMNgqFEnUU=; b=LVIrC+6gFdvAs9iHm1fWn0ZF+i2F3mr1ITWdj3oGPDXRM4ZFTuoHgCSd YCz8wfWMaHyuFmqxycNU/wqKSX8WcwTR7xaCXnrGsPs8Sd+sN+VN/OnyT L0KH6Y2tDkcttpOoiK/XrQFCDgSgkIAxm/KxjYcF9danG4akvUodOKrce g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AgDUpdpc/xbLJq1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYJ6USESKIQKB4h7i38lmGeBEANUAgcBAQEJAwEBGA0KAQGBS4J1AoI?= =?us-ascii?q?8OBMBAwEBBAEBAgEEbRwMhUoBAQEDASMrIQ8LCxgqAgIxFREOBwQBHASDAQG?= =?us-ascii?q?Bew8PrXmBL4QyAYVwCgaBM4FPiheBf4E4DBOCTD6CYQICgSwBEgFsgj0yggQ?= =?us-ascii?q?iBJMhlDgJgguCCYECgxaMPRuMLolAkwyLOYJ5AgQGBQIVgWYhNjBxMxoIGxU?= =?us-ascii?q?7KgGCQRMrgV0Xg0yKVT0DMAEPjg0PFwSCKAEB?= X-IronPort-AV: E=Sophos;i="5.60,468,1549929600"; d="asc'?scan'208";a="12077419" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2019 11:31:50 +0000 Received: from [10.61.193.41] ([10.61.193.41]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x4EBVnlS015916 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 May 2019 11:31:50 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_FAE8FE3A-3301-4F23-B51C-44D8A3FBB2FC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 14 May 2019 13:31:48 +0200 References: <17454.1557618668@localhost> To: mud@ietf.org In-Reply-To: <17454.1557618668@localhost> Message-Id: X-Mailer: Apple Mail (2.3445.104.8) X-Outbound-SMTP-Client: 10.61.193.41, [10.61.193.41] X-Outbound-Node: aer-core-4.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: Tue, 14 May 2019 11:31:55 -0000 --Apple-Mail=_FAE8FE3A-3301-4F23-B51C-44D8A3FBB2FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 May 2019, at 01:51, Michael Richardson = wrote: >=20 >=20 > {did the list transition go as intended?} >=20 > What should a MUD-manager do if a MUD file can no longer be found at = the > provided URL? Perhaps this is equivalent to the signature not = verifying. >=20 > I'm thinking specifically of a case where a device is initially = created by a > contractor, they dutifully create a MUD file, provide it to the = customer to > host, and then.. the customer forgets... marketing reorganizes the web = site, > etc. and so the MUD file goes missing. >=20 > 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 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. 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. Eliot >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > -- > You received this message because you are subscribed to the Google = Groups "mud-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to mud-discuss+unsubscribe@googlegroups.com. > To post to this group, send email to mud-discuss@googlegroups.com. > To view this discussion on the web visit = https://groups.google.com/d/msgid/mud-discuss/17454.1557618668%40localhost= . > For more options, visit https://groups.google.com/d/optout. --Apple-Mail=_FAE8FE3A-3301-4F23-B51C-44D8A3FBB2FC 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXNqnJAAKCRBugA9nE248 uIqyAKCh//MeLY4AWca2tzMI4aUjErKcRQCfRNH7LsQdCCIy9FSJWhFBMPWXDBc= =96i5 -----END PGP SIGNATURE----- --Apple-Mail=_FAE8FE3A-3301-4F23-B51C-44D8A3FBB2FC-- From nobody Tue May 14 04:38: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 826421201D7 for ; Tue, 14 May 2019 04:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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_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 EgF_5enW7ZpE for ; Tue, 14 May 2019 04:37:59 -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 754EA1200A4 for ; Tue, 14 May 2019 04:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20488; q=dns/txt; s=iport; t=1557833878; x=1559043478; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=1q/5g7uQPNEa2pWa29tQzDTbNBIlIBnh02d5Qg6bQyc=; b=avBaZGRXn3EoO+s79A2pQhn5wv//38PoLyYDH+gh6FeByiTnLbgZ9dYe mnfCGpndHhXPV+s/G4NJnHKgz9wyTFPeB/j5GlZSmM8r+IiYHpJRpfY5U ooUUGVW0rf/U2FDPke9l9qZ6cZaILpxCBtm5sgjw7ZhFV/BfTggi2lxu9 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAADSp9pc/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJ6USESKIQKB4h7jCSJP4kZhg+BEANUAgcBAQEJAwE?= =?us-ascii?q?BGAEFEQEBgUuCdQKCPDgTAQMBAQQBAQIBBG0cDIVKAQEBAwEjBCcrBQsLGCc?= =?us-ascii?q?DAgIhEBURBggHBAEcBIMBAYFqAw4PD61/fDOEMgGBFII8DYITCgaBM4FPhze?= =?us-ascii?q?CYIF/gREnH4JMPoIaRwICFQOBFAEMBgGDKTKCJgSKfTqHGFKHHow1LDkJggu?= =?us-ascii?q?CCYECgxaBK4c8g1YbghSKGolAjVaFNoFPiTowgnkCBAYFAhWBZiE2MHEzGgg?= =?us-ascii?q?bFTsqAYJBEyuBWINoilU9AzABAQ6ODg4XgiwBAQ?= X-IronPort-AV: E=Sophos;i="5.60,468,1549929600"; d="asc'?scan'208,217";a="12081366" 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; 14 May 2019 11:37:56 +0000 Received: from [10.61.193.41] ([10.61.193.41]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x4EBbtGO028427 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 May 2019 11:37:55 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_90693DE8-893C-47C0-9CE7-138A63C13737"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 14 May 2019 13:37:54 +0200 In-Reply-To: Cc: mud@ietf.org To: "M. Ranganathan" References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> X-Mailer: Apple Mail (2.3445.104.8) X-Outbound-SMTP-Client: 10.61.193.41, [10.61.193.41] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] Convening MUD calls, + next steps 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, 14 May 2019 11:38:02 -0000 --Apple-Mail=_90693DE8-893C-47C0-9CE7-138A63C13737 Content-Type: multipart/alternative; boundary="Apple-Mail=_B9E10C43-329E-4504-8CBA-632479547929" --Apple-Mail=_B9E10C43-329E-4504-8CBA-632479547929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ranga, Following up on this message below, the ACL model has actions available. = One of the things we have spoken about was a means by which = manufacturers could collect intelligence about how the MUD file is being = interpreted. That is- if the implementation is dropping packets or = would drop packets based on the MUD file, provide some sort of aggregate = feedback. We need a draft on that alongside an implementation. We talked a bit about this at one point, and the key is just making sure = to match the drop against a particular MUD rule. =46rom an = implementation standpoint that means logging drops, for a specific = device, matching that device to a MUD URL, and then having some sort of = contact information available for this purpose. That=E2=80=99s a draft right there. What I want to avoid is advising complex behaviors or behaviors that = might require substantial resources on the part of the MUD manager. An = example of that is logging, because it can be resource-intensive. If = that is something that an administrator wants, do it in your MUD manager = implementation. At least that=E2=80=99s my thinking. Am I wrong? Eliot > On 16 Apr 2019, at 18:43, M. Ranganathan wrote: >=20 >=20 >=20 > On Mon, Apr 15, 2019 at 9:59 PM Michael Richardson = > wrote: >=20 > M. Ranganathan > wrote: > > One could presumably add action hints in the ACE on what to do = with access > > violations (right now it is just "accept" or "deny" but one = could be kinder > > and gentler - e.g. add a "log" action - which is to be = interpreted as "log > > violations but allow"). For example: >=20 > > "volations": { > > "forwarding" : "accept-log" > > } >=20 > As another example, let's say that there is access needed to a large = number > of content servers. Simple examples would include firmware updates = which are > stored in non-deterministic CDNs, but also just consider a netflix = model. >=20 > Consider a rule that basically says, "device X" -> "all of AWS space". > One the one hand, that's pretty drastic! The device could attack all = sorts > of things that live in AWS "Elastic IP" space. On the other hand, = that space > does not include root name servers, core ISP routers, university dorm > computers, and a lot of other critical infrastructure. > (Can we find out what is "all of AWS space"? I'm sure the list is = long in > v4, but in v6, it's probably not more than a few dozen prefixes) >=20 > However, if we would mitigate such a "all of AWS space" rule to = include > the bandwidth limits often discussed, or better yet, number of = simulatenous > connections (or more precisely, number of unique SYN packets/hour), = then that > would seriously limit things, and would work very well for firmware = updates, > and yes, maybe even netflix. >=20 > -- > Michael Richardson >, Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > After some thought, I realized I mis-stated my suggested enhancement = (possibly confusing) so let me try again but I'll keep it at a = conceptual level. >=20 > A MUD file is essentially an if-then-else construct >=20 >=20 > if (ACE[0] is OK) then forward > else if (ACE[1] is OK) then forward > ... > else > DROP >=20 > I think what we're agreed on is that the DROP is too harsh as a = blanket policy to apply. I am saying that we should be able to specify = what to do if no forward action is possible. >=20 > That is, we could specify WHEN to drop, or WHEN we want to log and = forward using matches on various conditions: >=20 > e.g. >=20 > DROP if packet is from a local network from / to Thing (assuming we = don't want to tolerate East-west violations) > FORWARD and log if packet is from Thing to DNS named host (and inform = the Manufacturer). >=20 > This is at the conceptual level. I am not sure how to work this neatly = into the MUD YANG model etc. Here is a very rough example > "ietf-mud:mud": { > "mud-version": 1, > "mud-url": "https://controllerclass-test.nist.local/super1 = ", > "last-update": "2018-03-11T19:44:23+01:00", > "cache-validity": 48, > "is-supported": true, > "systeminfo": "https://mud.nist.local/toaster = ", > "from-device-policy": { > "access-lists": { > "access-list": [ > { > "name": "mud-38382-v4fr" > } > ] > } > }, > "to-device-policy": { > "access-lists": { > "access-list": [ > { > "name": "mud-38382-v4to" > } > ] > } > }, > "violations" : { > "local-networks" : "drop", > "dns-name" : "forward-log" > } > } >=20 > (I added the last piece). Is there any way of stating this neatly? >=20 > Thanks for reading. >=20 > Regards, >=20 > Ranga. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > You received this message because you are subscribed to the Google = Groups "mud-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to mud-discuss+unsubscribe@googlegroups.com = . > To post to this group, send email to mud-discuss@googlegroups.com = . > To view this discussion on the web visit = https://groups.google.com/d/msgid/mud-discuss/10007.1555379966%40localhost= = . > For more options, visit https://groups.google.com/d/optout = . >=20 >=20 > -- > M. Ranganathan >=20 >=20 > -- > You received this message because you are subscribed to the Google = Groups "mud-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to mud-discuss+unsubscribe@googlegroups.com = . > To post to this group, send email to mud-discuss@googlegroups.com = . > To view this discussion on the web visit = https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pKaJzP%3DeU4W= vTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com = . > For more options, visit https://groups.google.com/d/optout = . --Apple-Mail=_B9E10C43-329E-4504-8CBA-632479547929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ranga,

Following up = on this message below, the ACL model has actions available.  One of = the things we have spoken about was a means by which manufacturers could = collect intelligence about how the MUD file is being interpreted. =  That is- if the implementation is dropping packets or would drop = packets based on the MUD file, provide some sort of aggregate feedback. =  We need a draft on that alongside an implementation.

We talked a bit about = this at one point, and the key is just making sure to match the drop = against a particular MUD rule.  =46rom an implementation standpoint = that means logging drops, for a specific device, matching that device to = a MUD URL, and then having some sort of contact information available = for this purpose.

That=E2=80=99s a draft right there.

What I want to avoid is advising = complex behaviors or behaviors that might require substantial resources = on the part of the MUD manager.  An example of that is logging, = because it can be resource-intensive.  If that is something that an = administrator wants, do it in your MUD manager implementation.

At least that=E2=80=99s = my thinking.  Am I wrong?

Eliot

On 16 = Apr 2019, at 18:43, M. Ranganathan <mranga@gmail.com> wrote:



On Mon, Apr = 15, 2019 at 9:59 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

M. Ranganathan <mranga@gmail.com> wrote:
    > One could presumably add action hints in the ACE on = what to do with access
    > violations (right now it is just "accept" or "deny" = but one could be kinder
    > and gentler - e.g. add a "log" action - which is to = be interpreted as "log
    > violations but allow"). For example:

    > "volations": {
    > "forwarding" : "accept-log"
    > }

As another example, let's say that there is access needed to a large = number
of content servers.  Simple examples would include firmware updates = which are
stored in non-deterministic CDNs, but also just consider a netflix = model.

Consider a rule that basically says, "device X" -> "all of AWS = space".
One the one hand, that's pretty drastic!  The device could attack = all sorts
of things that live in AWS "Elastic IP" space.  On the other hand, = that space
does not include root name servers, core ISP routers, university dorm
computers, and a lot of other critical infrastructure.
(Can we find out what is "all of AWS space"?  I'm sure the list is = long in
v4, but in v6, it's probably not more than a few dozen prefixes)

However, if we would mitigate such a "all of AWS space" rule to = include
the bandwidth limits often discussed, or better yet, number of = simulatenous
connections (or more precisely, number of unique SYN packets/hour), then = that
would seriously limit things, and would work very well for firmware = updates,
and yes, maybe even netflix.

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



After some thought, I realized I mis-stated my suggested = enhancement (possibly confusing) so let me try again but I'll keep it at = a conceptual level.

A MUD file is essentially an = if-then-else construct


if (ACE[0] is OK) then = forward
else if (ACE[1] is OK) then = forward
...
else
     DROP

I think what we're agreed on is that = the DROP is too harsh as a blanket policy to apply. I am saying that we = should be able to specify what to do if no forward action is = possible.

That is, we could specify WHEN to drop, or WHEN we want to = log and forward using matches on various conditions:

e.g.

DROP= if packet is from a local network from / to Thing (assuming we don't = want to tolerate East-west violations)
FORWARD and log if packet is from Thing to DNS named host = (and inform the Manufacturer).

This is at the conceptual level. I am = not sure how to work this neatly into the MUD YANG model etc. Here is a = very rough example
 "ietf-mud:mud": {
    = "mud-version": 1,
    "mud-url": "https://controllerclass-test.nist.local/super1",
    "last-update": = "2018-03-11T19:44:23+01:00",
    = "cache-validity": 48,
    "is-supported": = true,
    "systeminfo": "https://mud.nist.local/toaster",
    "from-device-policy": {
      "access-lists": {
        "access-list": = [
          = {
          &nb= sp; "name": "mud-38382-v4fr"
          }
        ]
      }
    },
    = "to-device-policy": {
      = "access-lists": {
       = "access-list": [
          {
          &nb= sp; "name": "mud-38382-v4to"
          }
        ]
      }
    },
    "violations" : {
          &nb= sp; "local-networks" : "drop",
          &nb= sp; "dns-name" : "forward-log"
    = }
  }

(I added the last piece). Is there any way of stating this = neatly?

Thanks for reading.

Regards,

Ranga.








 

--
You received this message because you are subscribed to the Google = Groups "mud-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send = an email to mud-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to mud-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mud-discuss/10007.1555379966%= 40localhost.
For more options, visit https://groups.google.com/d/optout.


--
M. = Ranganathan


--
You received this message because you are subscribed to the Google = Groups "mud-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send = an email to mud-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to mud-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pK= aJzP%3DeU4WvTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

= --Apple-Mail=_B9E10C43-329E-4504-8CBA-632479547929-- --Apple-Mail=_90693DE8-893C-47C0-9CE7-138A63C13737 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXNqokgAKCRBugA9nE248 uNL4AKCXP8lhW4OXS/9njLOSzgk40dUmlACgjXpQ1HqdZ/CcNZJXkWFvdLAjjR4= =vKcs -----END PGP SIGNATURE----- --Apple-Mail=_90693DE8-893C-47C0-9CE7-138A63C13737-- From nobody Tue May 14 12:03:57 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 5F87A1200C4 for ; Tue, 14 May 2019 12:03:55 -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_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 ylwq_h45L4Fr for ; Tue, 14 May 2019 12:03:52 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 1967D120021 for ; Tue, 14 May 2019 12:03:52 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id 9so563466itf.4 for ; Tue, 14 May 2019 12:03:52 -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=LmEmScOfBsH4VjrpQDLLg6Yk+x4+aKimJ2SyiIk5Xfc=; b=tjSOBoc0VFjYKd+ftJievQYd7E0YEqOj1fxme1KR7MUsKhcUjbkFuyXnmBinbV2Dwi tsnaFpg29UAefbRWgXYCG4jLMmLIZugv1J4M8nXOi6ty8COTbl0PulJccxl/y5zPbZdK y7q2jRydLFkQz10NKyGF8OSqsrxBqdbfKjNJezFH/CX7eRZ/CmYkPThy12TbyU8lQKWR eMz7mKQcyPSXcDRWo8uvKfc8L9SmGgrI+cvOAdtGWZ4TiDMyzk1GhpAcFYwqiqTiWP8b Dji8dS+kANLNrNmPFLf64WF+azElFiqDdGl5mubgFd74lglo6XujXTG1YZZjv6VBkwoC EIrA== 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=LmEmScOfBsH4VjrpQDLLg6Yk+x4+aKimJ2SyiIk5Xfc=; b=brsrf/Ig3/3ZfcIcPWVtwRoOm/a/tRXDahvIzo/1uTbLFq7sg3Ac1rPp3G69l1uL3u bYitocodTNGKSrKmen6FdKAIAcoOjli8YFkxnoVxnl0U7NoqbaQRZkMNXfIx2DKiy0je mfcTCkIRSlwjnvGCZdTtSAZMloQ0izEAtoeu3FBOUrEIejFQYO5fc0NNPQxa5DPgfKDu EFj4WsOmDZnt5OvFr+skqnS0dXFGZ4fvuaKjoikGPpbVlnYTUZEKHTd3szCSV2x5EuFA dXsRYErSMCIrZ8MT4XcxsgdQaUn3QUr1ouYV2DXgup6lUemT+/X6nwo2QP9VDmoCcQv5 aXlw== X-Gm-Message-State: APjAAAULibsPDKbmJX4bLRubBUC1op2MhnQF0n8Y0sKb6nc6npfXqosF 6kr/CDRggH1e2WcG1gO9q8DmITCTzmmOSjl5+7g= X-Google-Smtp-Source: APXvYqwcUfnxVUn3HP02pPFf+t2acI7RgzeypBbOsu4hfSn4MStBZibF6hciVMNjHv0gDUSHyyUvhS2xewleE8Sfha0= X-Received: by 2002:a24:320c:: with SMTP id j12mr4424267ita.131.1557860631158; Tue, 14 May 2019 12:03:51 -0700 (PDT) MIME-Version: 1.0 References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> In-Reply-To: From: "M. Ranganathan" Date: Tue, 14 May 2019 15:03:14 -0400 Message-ID: To: Eliot Lear Cc: mud@ietf.org Content-Type: multipart/alternative; boundary="00000000000087a72b0588ddb17c" Archived-At: Subject: Re: [Mud] Convening MUD calls, + next steps 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, 14 May 2019 19:03:55 -0000 --00000000000087a72b0588ddb17c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Eliot, On Tue, May 14, 2019 at 7:37 AM Eliot Lear wrote: > Hi Ranga, > > Following up on this message below, the ACL model has actions available. > One of the things we have spoken about was a means by which manufacturers > could collect intelligence about how the MUD file is being interpreted. > That is- if the implementation is dropping packets or would drop packets > based on the MUD file, provide some sort of aggregate feedback. We need = a > draft on that alongside an implementation. > Defining the format of such feedback would be useful I think. > We talked a bit about this at one point, and the key is just making sure > to match the drop against a particular MUD rule. From an implementation > standpoint that means logging drops, for a specific device, matching that > device to a MUD URL, and then having some sort of contact information > available for this purpose. > Request some clarifications on the proposed behavior: MUD is a series of "ACCEPT" rules followed by an implicit DROP rule. So how can we know that a specific MUD rule caused a packet to be dropped? All we know when the packet is dropped (or marked for drop) is that NO mud rule allowed the packet to proceed. Thanks, Ranga > > That=E2=80=99s a draft right there. > > What I want to avoid is advising complex behaviors or behaviors that migh= t > require substantial resources on the part of the MUD manager. An example > of that is logging, because it can be resource-intensive. If that is > something that an administrator wants, do it in your MUD manager > implementation. > > At least that=E2=80=99s my thinking. Am I wrong? > > Eliot > > On 16 Apr 2019, at 18:43, M. Ranganathan wrote: > > > > On Mon, Apr 15, 2019 at 9:59 PM Michael Richardson > wrote: > >> >> M. Ranganathan wrote: >> > One could presumably add action hints in the ACE on what to do wit= h >> access >> > violations (right now it is just "accept" or "deny" but one could >> be kinder >> > and gentler - e.g. add a "log" action - which is to be interpreted >> as "log >> > violations but allow"). For example: >> >> > "volations": { >> > "forwarding" : "accept-log" >> > } >> >> As another example, let's say that there is access needed to a large >> number >> of content servers. Simple examples would include firmware updates whic= h >> are >> stored in non-deterministic CDNs, but also just consider a netflix model= . >> >> Consider a rule that basically says, "device X" -> "all of AWS space". >> One the one hand, that's pretty drastic! The device could attack all >> sorts >> of things that live in AWS "Elastic IP" space. On the other hand, that >> space >> does not include root name servers, core ISP routers, university dorm >> computers, and a lot of other critical infrastructure. >> (Can we find out what is "all of AWS space"? I'm sure the list is long = in >> v4, but in v6, it's probably not more than a few dozen prefixes) >> >> However, if we would mitigate such a "all of AWS space" rule to include >> the bandwidth limits often discussed, or better yet, number of >> simulatenous >> connections (or more precisely, number of unique SYN packets/hour), then >> that >> would seriously limit things, and would work very well for firmware >> updates, >> and yes, maybe even netflix. >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> > After some thought, I realized I mis-stated my suggested enhancement > (possibly confusing) so let me try again but I'll keep it at a conceptual > level. > > A MUD file is essentially an if-then-else construct > > > if (ACE[0] is OK) then forward > else if (ACE[1] is OK) then forward > ... > else > DROP > > I think what we're agreed on is that the DROP is too harsh as a blanket > policy to apply. I am saying that we should be able to specify what to do > if no forward action is possible. > > That is, we could specify WHEN to drop, or WHEN we want to log and forwar= d > using matches on various conditions: > > e.g. > > DROP if packet is from a local network from / to Thing (assuming we don't > want to tolerate East-west violations) > FORWARD and log if packet is from Thing to DNS named host (and inform the > Manufacturer). > > This is at the conceptual level. I am not sure how to work this neatly > into the MUD YANG model etc. Here is a very rough example > "ietf-mud:mud": { > "mud-version": 1, > "mud-url": "https://controllerclass-test.nist.local/super1", > "last-update": "2018-03-11T19:44:23+01:00", > "cache-validity": 48, > "is-supported": true, > "systeminfo": "https://mud.nist.local/toaster", > "from-device-policy": { > "access-lists": { > "access-list": [ > { > "name": "mud-38382-v4fr" > } > ] > } > }, > "to-device-policy": { > "access-lists": { > "access-list": [ > { > "name": "mud-38382-v4to" > } > ] > } > }, > "violations" : { > "local-networks" : "drop", > "dns-name" : "forward-log" > } > } > > (I added the last piece). Is there any way of stating this neatly? > > Thanks for reading. > > Regards, > > Ranga. > > > > > > > > > > >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "mud-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to mud-discuss+unsubscribe@googlegroups.com. >> To post to this group, send email to mud-discuss@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/mud-discuss/10007.1555379966%40localho= st >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > M. Ranganathan > > > -- > You received this message because you are subscribed to the Google Groups > "mud-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mud-discuss+unsubscribe@googlegroups.com. > To post to this group, send email to mud-discuss@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pKaJzP%3DeU4= WvTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > > > --=20 M. Ranganathan --00000000000087a72b0588ddb17c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Eliot,

On Tue, May 14, 2019 at 7= :37 AM Eliot Lear <lear@cisco.com&= gt; wrote:
Hi Ranga,

Following= up on this message below, the ACL model has actions available.=C2=A0 One o= f the things we have spoken about was a means by which manufacturers could = collect intelligence about how the MUD file is being interpreted.=C2=A0 Tha= t is- if the implementation is dropping packets or would drop packets based= on the MUD file, provide some sort of aggregate feedback.=C2=A0 We need a = draft on that alongside an implementation.
Defining the format of such feedback would be useful I think.

<= div style=3D"overflow-wrap: break-word;">

We talked a bi= t about this at one point, and the key is just making sure to match the dro= p against a particular MUD rule.=C2=A0 From an implementation standpoint th= at means logging drops, for a specific device, matching that device to a MU= D URL, and then having some sort of contact information available for this = purpose.

Request some clarifica= tions on the proposed behavior:

MUD is a serie= s of "ACCEPT" rules followed by an implicit DROP rule. So how can= we know that a specific MUD rule caused a packet to be dropped? All we kno= w when the packet is dropped (or marked for drop) is that NO mud rule allow= ed the packet to proceed.

Thanks,

Ranga


=C2=A0

That=E2=80=99s a draft right there.

What I want to = avoid is advising complex behaviors or behaviors that might require substan= tial resources on the part of the MUD manager.=C2=A0 An example of that is = logging, because it can be resource-intensive.=C2=A0 If that is something t= hat an administrator wants, do it in your MUD manager implementation.
=

At least that=E2=80=99s my thinking.=C2=A0 Am I wrong?<= /div>

Eliot

O= n 16 Apr 2019, at 18:43, M. Ranganathan <mranga@gmail.com> wrote:

=


=
On Mon, Apr 15, 2019 at 9:59 PM Micha= el Richardson <mcr+ietf@sandelman.ca> wrote:

M. Ranganathan <mr= anga@gmail.com> wrote:
=C2=A0 =C2=A0 > One could presumably add action hints in the ACE on what= to do with access
=C2=A0 =C2=A0 > violations (right now it is just "accept" or &= quot;deny" but one could be kinder
=C2=A0 =C2=A0 > and gentler - e.g. add a "log" action - which = is to be interpreted as "log
=C2=A0 =C2=A0 > violations but allow"). For example:

=C2=A0 =C2=A0 > "volations": {
=C2=A0 =C2=A0 > "forwarding" : "accept-log"
=C2=A0 =C2=A0 > }

As another example, let's say that there is access needed to a large nu= mber
of content servers.=C2=A0 Simple examples would include firmware updates wh= ich are
stored in non-deterministic CDNs, but also just consider a netflix model.
Consider a rule that basically says, "device X" -> "all o= f AWS space".
One the one hand, that's pretty drastic!=C2=A0 The device could attack = all sorts
of things that live in AWS "Elastic IP" space.=C2=A0 On the other= hand, that space
does not include root name servers, core ISP routers, university dorm
computers, and a lot of other critical infrastructure.
(Can we find out what is "all of AWS space"?=C2=A0 I'm sure t= he list is long in
v4, but in v6, it's probably not more than a few dozen prefixes)

However, if we would mitigate such a "all of AWS space" rule to i= nclude
the bandwidth limits often discussed, or better yet, number of simulatenous=
connections (or more precisely, number of unique SYN packets/hour), then th= at
would seriously limit things, and would work very well for firmware updates= ,
and yes, maybe even netflix.

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



After some thought, I realized I mis-s= tated my suggested enhancement (possibly confusing) so let me try again but= I'll keep it at a conceptual level.

A MU= D file is essentially an if-then-else construct

if (ACE[0] is OK) then forward
else if (ACE[1] is OK= ) then forward
...
else
=C2=A0=C2=A0=C2=A0=C2= =A0 DROP

I think what we're agreed on is that = the DROP is too harsh as a blanket policy to apply. I am saying that we sho= uld be able to specify what to do if no forward action is possible.

That is, we could specify WHEN to drop, or WHEN we wa= nt to log and forward using matches on various conditions:

e.g.

DROP if packet is from a local = network from / to Thing (assuming we don't want to tolerate East-west v= iolations)
FORWARD and log if packet is from Thing to DNS nam= ed host (and inform the Manufacturer).

This i= s at the conceptual level. I am not sure how to work this neatly into the M= UD YANG model etc. Here is a very rough example
=C2=A0"= ietf-mud:mud": {
=C2=A0=C2=A0=C2=A0 "mud-version": 1,
= =C2=A0=C2=A0=C2=A0 "mud-url": "https://controllerclass-tes= t.nist.local/super1",
=C2=A0=C2=A0=C2=A0 "last-update"= ;: "2018-03-11T19:44:23+01:00",
=C2=A0=C2=A0=C2=A0 "cache= -validity": 48,
=C2=A0=C2=A0=C2=A0 "is-supported": true,<= br>=C2=A0=C2=A0=C2=A0 "systeminfo": "https://mud.nist.local/toaster&qu= ot;,
=C2=A0=C2=A0=C2=A0 "from-device-policy": {
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "access-lists": {
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "access-list": [
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "name": "mud-38382-v4fr"=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
= =C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0 "to-device-policy": {=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "access-lists": {
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "access-list": [
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "name": "mud-3838= 2-v4to"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 }
=C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0 "vi= olations" : {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "local-networks" : "drop",
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "dn= s-name" : "forward-log"
=C2=A0=C2=A0=C2=A0 }
= =C2=A0 }

(I added the last piece). Is there any wa= y of stating this neatly?

Thanks for reading. =

Regards,

Ranga.
<= /div>





<= /div>



=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;mud-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to mud-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to mud-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mud-discuss/10007.15553799= 66%40localhost.
For more options, visit https://groups.google.com/d/optout.


--
=
M. Ranganathan


--
You received this message because you are subscribed to the Google Groups &= quot;mud-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to mud-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to mud-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mud-discuss/CAHiu4JO-iY1h02pKaJzP%3= DeU4WvTn_9HpghnPdynrxEupwh8CPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
<= div>
M. Ranganathan

--00000000000087a72b0588ddb17c-- From nobody Tue May 14 13:12: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 21DC31200DE for ; Tue, 14 May 2019 13:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 NXUs8Lu-tQhR for ; Tue, 14 May 2019 13:11:58 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 0EFAB120074 for ; Tue, 14 May 2019 13:11:57 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id d13so588516qth.5 for ; Tue, 14 May 2019 13:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version; bh=7+bGWLTf0Ma9FIY0mrNDysJEvArxInWECCJzKhHFarI=; b=pWw28VTiP1ZnB8iekcMsHgbwvBz7QnTFepXN3+PqhATr6dzZWQaUqtKnMLsW0IVbcw 2rQh66dP/xYDl9ReWTjFf4/nDNW/XATUM0ZLg7ozzfWtgFV1rPF/mvHP4EdcA+hyHwjS 0lJp+LPcbv8XXsgP6plmAi0L9Cq5VeCZ4p9ngUwgo/CHaDRezSb/lDBuDmcVSfo/sp9m YyMxsdBBQggviemRhwufoX1+5Gv5AwlXMUqiPqafrVXLEBAxl3xymG7TY0ATlun+C7Wc XDwJg6J8pwMZ+1WINWLTA+Q5JQ0nQN9Db3gWIKdddlHymheAuvK8vxfwZSqw9RvAqPk3 ANfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=7+bGWLTf0Ma9FIY0mrNDysJEvArxInWECCJzKhHFarI=; b=e0MIu7bn76yGq7KGqafdFMGy8m/T+ZTOSqznhU7Q3eQkwKRLqEXcBseYx8n3KGRBp+ SgizRi7wkJvmxawFxY2wD4fwEgsHG3p41yG+HDLLV7UMGiwYxjUgPuiFLUCdiO+QlEWY xQJsenD2hoe6w6rgr/zhtvQgK1jVxkwByT7l3a2fibwQpu3+xBHf3dJd67IAmdwx+eQ+ DmlnmgBERAvtWZB5IDOHL1k2W1i04X9VBir/pjOHCU1p7TdIcZ7i+h+jIPDdxQXuWWFR p6D5aNjGprSPj7qhfiBlpMVgOs9pqs34NtYQoO7arSdJkJrcaCKg2hiepKnLvnUPHd6Z e9oQ== X-Gm-Message-State: APjAAAWWSmuFihrcguhxljLAFbnN3mHNIE+wBn+cVg8x1Fu95XSgKC3o SDB/5QA6VWXW0mzE4rs7wNpPqGfUUZtYOA== X-Google-Smtp-Source: APXvYqzt5Kt0X8SEm9TTjKkr/5I3UGZ3iM1CeXUePIyuc0K46VSrDr3otu+qyuYeF1IE3R+9S09NqQ== X-Received: by 2002:a0c:98ab:: with SMTP id f40mr22105175qvd.177.1557864716778; Tue, 14 May 2019 13:11:56 -0700 (PDT) Received: from [192.168.1.60] (modemcable138.218-70-69.static.videotron.ca. [69.70.218.138]) by smtp.gmail.com with ESMTPSA id c30sm5533357qta.25.2019.05.14.13.11.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 13:11:55 -0700 (PDT) From: "Marc Blanchet" To: mud@ietf.org Date: Tue, 14 May 2019 16:11:54 -0400 X-Mailer: MailMate (1.12.5r5632) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Mud] mud-discuss google group removed 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, 14 May 2019 20:12:01 -0000 Hello, as stated before, the mud-discuss google group has now been removed. Please continue discussion on this list. Regards, Marc. From nobody Tue May 14 13:41:27 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 C771B120285 for ; Tue, 14 May 2019 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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_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 eqbNFBHPVd4v for ; Tue, 14 May 2019 13:41:14 -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 3B5C9120271 for ; Tue, 14 May 2019 13:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6175; q=dns/txt; s=iport; t=1557866474; x=1559076074; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=tdud47GRGgDeSo0KfS8aht0IUoQvDh5XXXNTPH9A9S8=; b=fXVUbTGA66Ytrz6rUwIl6+NAlNt5Dbu+lnl41jDFEG2fPk+K1vd5tFyq +1e+RpNUAKy6HQFSJrfEHuBCdWxMu6E7uJGCSfO/A6u2feO+HOiaoI8/w zbBesCFyTbUOI7zn20fX9yiFSB2pDuhEUPLxFCa213SuL9FRLLT+1VDPt Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABxJ9tc/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGDSiESKIQRiHuMJYk/iRmFe4F7AgcBAQEJAwE?= =?us-ascii?q?BLwEBhEACgkA2Bw4BAwEBBAEBAgEEbSiFSgEBAQMBI1YFCwsYJwMCAiElEQY?= =?us-ascii?q?TgyIBgWoDDg+raoEvhUeCOw2CExCBMwGBToMWhwGBf4ERJx+CTD6CGoU0MoI?= =?us-ascii?q?mBIs3h2qTfzkJgguCCYECi32DVhuMLolAlFuJaoJ5AgQGBQIVgVYLJoFXMxo?= =?us-ascii?q?IGxVlAYJBPpAVPQMwkG8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,470,1549929600"; d="asc'?scan'208,217";a="12032195" 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; 14 May 2019 20:41:11 +0000 Received: from [10.61.209.92] ([10.61.209.92]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x4EKfBb6002610 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 May 2019 20:41:11 GMT From: Eliot Lear Message-Id: <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E88EF65F-37C9-4F64-83FA-BE1E161D3080"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 14 May 2019 22:41:10 +0200 In-Reply-To: Cc: mud@ietf.org To: "M. Ranganathan" References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> X-Mailer: Apple Mail (2.3445.104.8) X-Outbound-SMTP-Client: 10.61.209.92, [10.61.209.92] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Mud] Convening MUD calls, + next steps 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, 14 May 2019 20:41:24 -0000 --Apple-Mail=_E88EF65F-37C9-4F64-83FA-BE1E161D3080 Content-Type: multipart/alternative; boundary="Apple-Mail=_BFDB34E0-1F50-48B1-971C-D9E1B6257F42" --Apple-Mail=_BFDB34E0-1F50-48B1-971C-D9E1B6257F42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 May 2019, at 21:03, M. Ranganathan wrote: >=20 > Hello Eliot, >=20 > On Tue, May 14, 2019 at 7:37 AM Eliot Lear > wrote: > Hi Ranga, >=20 > Following up on this message below, the ACL model has actions = available. One of the things we have spoken about was a means by which = manufacturers could collect intelligence about how the MUD file is being = interpreted. That is- if the implementation is dropping packets or = would drop packets based on the MUD file, provide some sort of aggregate = feedback. We need a draft on that alongside an implementation. >=20 > Defining the format of such feedback would be useful I think. >=20 >=20 > We talked a bit about this at one point, and the key is just making = sure to match the drop against a particular MUD rule. =46rom an = implementation standpoint that means logging drops, for a specific = device, matching that device to a MUD URL, and then having some sort of = contact information available for this purpose. >=20 > Request some clarifications on the proposed behavior: >=20 > MUD is a series of "ACCEPT" rules followed by an implicit DROP rule. = So how can we know that a specific MUD rule caused a packet to be = dropped? All we know when the packet is dropped (or marked for drop) is = that NO mud rule allowed the packet to proceed. >=20 On the whole this is generally true. The fact that the packet was = dropped means that NONE of the accept rules were met, and that=E2=80=99s = a lot of information right there. ie, my-controller, same-manufacturer = etc didn=E2=80=99t match, or they matched a reject rule. Do others have = thoughts there? Eliot --Apple-Mail=_BFDB34E0-1F50-48B1-971C-D9E1B6257F42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 May 2019, at 21:03, M. Ranganathan <mranga@gmail.com> = wrote:

Hello = Eliot,

On Tue, May 14, 2019 at 7:37 AM Eliot = Lear <lear@cisco.com> wrote:
Hi Ranga,

Following up on this message below, the ACL model has = actions available.  One of the things we have spoken about was a = means by which manufacturers could collect intelligence about how the = MUD file is being interpreted.  That is- if the implementation is = dropping packets or would drop packets based on the MUD file, provide = some sort of aggregate feedback.  We need a draft on that alongside = an implementation.

Defining the format of such feedback = would be useful I think.


We talked a bit about this at one point, and the key is just = making sure to match the drop against a particular MUD rule.  =46rom = an implementation standpoint that means logging drops, for a specific = device, matching that device to a MUD URL, and then having some sort of = contact information available for this = purpose.

Request some clarifications on the proposed behavior:

MUD = is a series of "ACCEPT" rules followed by an implicit DROP rule. So how = can we know that a specific MUD rule caused a packet to be dropped? All = we know when the packet is dropped (or marked for drop) is that NO mud = rule allowed the packet to proceed.


On the whole this is generally true.  The fact = that the packet was dropped means that NONE of the accept rules were = met, and that=E2=80=99s a lot of information right there.  ie, = my-controller, same-manufacturer etc didn=E2=80=99t match, or they = matched a reject rule.  Do others have thoughts = there?

Eliot


= --Apple-Mail=_BFDB34E0-1F50-48B1-971C-D9E1B6257F42-- --Apple-Mail=_E88EF65F-37C9-4F64-83FA-BE1E161D3080 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXNsn5gAKCRBugA9nE248 uOorAJ98zkRInwQ8jhR3igHkdDGwlwoXDQCeLgUNp3q/K2zxIcVyArG6PtvBAYU= =jbkN -----END PGP SIGNATURE----- --Apple-Mail=_E88EF65F-37C9-4F64-83FA-BE1E161D3080-- From nobody Tue May 14 15:13:48 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 CEA271200E6 for ; Tue, 14 May 2019 15:13:46 -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_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 WvufwKVP_iWX for ; Tue, 14 May 2019 15:13:45 -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 0349312003F for ; Tue, 14 May 2019 15:13:44 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DE8C3826E; Tue, 14 May 2019 18:12:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3BBDC1008; Tue, 14 May 2019 18:13:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3A4F1B3D; Tue, 14 May 2019 18:13:42 -0400 (EDT) From: Michael Richardson To: mud@ietf.org cc: "M. Ranganathan" , Eliot Lear In-Reply-To: <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@cisco.com> References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@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] Convening MUD calls, + next steps 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, 14 May 2019 22:13:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: mr> MUD is a series of "ACCEPT" rules followed by an implicit DROP rule= . So mr> how can we know that a specific MUD rule caused a packet to be drop= ped? mr> All we know when the packet is dropped (or marked for drop) is that= NO mr> mud rule allowed the packet to proceed. > On the whole this is generally true. The fact that the packet was dro= pped > means that NONE of the accept rules were met, and that=E2=80=99s a lo= t of information > right there. ie, my-controller, same-manufacturer etc didn=E2=80=99t = match, or they > matched a reject rule. Do others have thoughts there? But the rules aren't actually fully specific. They get instantiated: 1) source is the device (by... L2? L3? depends upon implementation) 2) destination is an IP, but rule is by name, so how did DNS resolve? It would be ideal if one could identify packets that would have matched if only the source was different, or the destination was resolved differently. This requires a bit of fuzzy matching against the drop-log. That probably accounts for 9 out 10 situations where packets were dropped that were not really malicious. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzbPZUACgkQgItw+93Q 3WXqcAf+Ows+2/1UIb8dtSQjNLk/mEnzPlM3yHOTQM+8yrgG7D6lPKTwrqVVDedh R7Zvp/ji9v7/BdsPz5q07v31L7a2T9EQdJawDLQ+ri22InnFzMHueGQw1rsVAGu0 2pJN/DuQj2SjdLsWkB8CZAnlW3sJDyFPkWdFMhk/l4DZkLtnLJWEBPKDwRJEITxj FV6SJEOVWBWtYqgR98DMRaf69nGsL8TTC669FzIb55a6xYVT9tsw8uSniTgb0KMj OwsfVq3v/xEq/Feg0UodXEA7E+UMO6L7tK1EHnZqZs13GDp+iT71K/g39ugPJJki mnd+z98QdQ0qFIYf9P6YjqtHTQ7YoQ== =aMj7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 14 17: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 E445212004C for ; Tue, 14 May 2019 17:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 FdO0WwsEDOjC for ; Tue, 14 May 2019 17:23:33 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 B85C012003E for ; Tue, 14 May 2019 17:23:33 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id q21so747608iog.13 for ; Tue, 14 May 2019 17:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=60Pw+knh4HNYj1vKIz8ktLfsECVXQkMATiktdUlcfr0=; b=ryTvP5izRAGLqfkccKFKEFMm8Bzoe1HbTSHdR2AiQpfLTZ1LrLJYlUFgEKK2F7D0Hd j2SoX1+Gh32GIQK4uto1W3gw4Ca8MgEuGQ8ZAxO4cotxINGNscsNqqLeMO69VzyHzGRL 2ke0SYJS+VnlmOhhinYm2BU97kanTTKzC7N0MQAW7QAl0rwxazlkUZ84tV9csc9ndtgj AbQD+45VZhb5fx945+AFWhmRtUcFuBsSZwEC7pjq+167u40NiYiu+GzrEq4FtVFNwb9Z w3YIhWfd54F4eepAIvzlmQiCYURlv9pIocnnWoEz5i6lrqBGzhPjNR7agNlwG8jRmpD4 9z5Q== 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=60Pw+knh4HNYj1vKIz8ktLfsECVXQkMATiktdUlcfr0=; b=nQtvYBoBFqhZg9j/qbqVWsdH3+0IaeSDUS3XCkcYawz2+CDo5x1hEzPXN1Q7TtLcrl q/UQEvxy/A0vFfsYuHi/c8dPI0jugeY3wojNjWaPAbmRNADXTKAh5mqdgQ3yaJDdBSUg blbFeqVHKnhIAyJwH2T9C0In4hyKK2b4MBEUmiDLc2ZnoPC82eDCOOq8tkSdmcoaC2bZ E9nDKqwICZx4Rd/+M1jZOyGLlve9dTGHuhwyPxl69yE1KNFHGLT3LA0rB4tx6L5AjGSD TtWiqjvm/B5eFPeeyk4/oEjbtAZ+D8HWZ+KFftnU1CV6DXqRaxZ+sWZ+Wuy0A/BC1CBl gHlg== X-Gm-Message-State: APjAAAUGadr1pBQVt9+GIwKYzeShg5c11yXQhl4niTQhUhwPRtYKjW46 LghN8Onf4kb46fzKZNGorMJINjBCsH5zjD09p6s= X-Google-Smtp-Source: APXvYqyjMoq0TGBg6E1OHj1WwF6hOenrR7J2KRrhiTizAE/0tsLC2uyq6nzTdWxKme47BhgyU2qxFKucDdG/p4MQ4k8= X-Received: by 2002:a5e:8904:: with SMTP id k4mr17440430ioj.264.1557879812783; Tue, 14 May 2019 17:23:32 -0700 (PDT) MIME-Version: 1.0 References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@cisco.com> <30445.1557872022@localhost> In-Reply-To: <30445.1557872022@localhost> From: "M. Ranganathan" Date: Tue, 14 May 2019 20:22:56 -0400 Message-ID: To: Michael Richardson Cc: mud@ietf.org, Eliot Lear Content-Type: multipart/alternative; boundary="000000000000d806aa0588e228f8" Archived-At: Subject: Re: [Mud] Convening MUD calls, + next steps 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, 15 May 2019 00:23:36 -0000 --000000000000d806aa0588e228f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 14, 2019 at 6:13 PM Michael Richardson wrote: > > Eliot Lear wrote: > mr> MUD is a series of "ACCEPT" rules followed by an implicit DROP > rule. So > mr> how can we know that a specific MUD rule caused a packet to be > dropped? > mr> All we know when the packet is dropped (or marked for drop) is > that NO > mr> mud rule allowed the packet to proceed. > > > On the whole this is generally true. The fact that the packet was > dropped > > means that NONE of the accept rules were met, and that=E2=80=99s a = lot of > information > > right there. ie, my-controller, same-manufacturer etc didn=E2=80=99= t match, > or they > > matched a reject rule. Do others have thoughts there? > > But the rules aren't actually fully specific. > They get instantiated: > 1) source is the device (by... L2? L3? depends upon implementation) > 2) destination is an IP, but rule is by name, so how did DNS resolve? > > It would be ideal if one could identify packets that would have matched i= f > only the source was different, or the destination was resolved differentl= y. > This requires a bit of fuzzy matching against the drop-log. > > That probably accounts for 9 out 10 situations where packets were dropped > that were not really malicious. > If we put a Source MAC/IP classification to activate a notification action in place of the implied drop, we could notify on the basis of those classifications. The implementation mechanism that is used to classify packets is not so relevant IMHO. What is important is that the packets, get classified and then get dropped because they misbehave. The MUD rules are stated on the basis of these classifications. So while you cannot state that a specific MUD rule caused a drop, you CAN state that a particular classification of packets caused a drop. Why not use the same classification mechanism that MUD uses to notify that a packet originated by the MUD-enabled device did something that the MUD rules disallowed? This would allow the administrator to select the notifications that he wants to provide to the manufacturer. > > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > --=20 M. Ranganathan --000000000000d806aa0588e228f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 14, 2019 at 6:13 PM Michael Richardso= n <mcr+ietf= @sandelman.ca> wrote:

Eliot Lear <lear@cis= co.com> wrote:
=C2=A0 =C2=A0 mr> MUD is a series of "ACCEPT" rules followed b= y an implicit DROP rule. So
=C2=A0 =C2=A0 mr> how can we know that a specific MUD rule caused a pack= et to be dropped?
=C2=A0 =C2=A0 mr> All we know when the packet is dropped (or marked for = drop) is that NO
=C2=A0 =C2=A0 mr> mud rule allowed the packet to proceed.

=C2=A0 =C2=A0 > On the whole this is generally true. The fact that the p= acket was dropped
=C2=A0 =C2=A0 > means that NONE of the accept rules were met, and that= =E2=80=99s a lot of information
=C2=A0 =C2=A0 > right there. ie, my-controller, same-manufacturer etc di= dn=E2=80=99t match, or they
=C2=A0 =C2=A0 > matched a reject rule. Do others have thoughts there?
But the rules aren't actually fully specific.
They get instantiated:
=C2=A0 1) source is the device (by... L2? L3? depends upon implementation)<= br> =C2=A0 2) destination is an IP, but rule is by name, so how did DNS resolve= ?

It would be ideal if one could identify packets that would have matched if<= br> only the source was different, or the destination was resolved differently.=
This requires a bit of fuzzy matching against the drop-log.

That probably accounts for 9 out 10 situations where packets were dropped that were not really malicious.

If we p= ut a Source MAC/IP classification to activate a notification action in plac= e of the implied drop, we could notify on the basis of=C2=A0
those classifications.

The implementation mec= hanism that is used to classify packets is not so relevant IMHO.
=
What is important is that the packets, get classified and t= hen get dropped because they
misbehave. The MUD rules are st= ated on the basis of these classifications.

S= o while you cannot state that a specific MUD rule caused a drop, you CAN st= ate that a particular classification of packets caused a drop.

Why not use the same classification mechanism that MUD use= s to notify that a packet originated by the
MUD-enabled devi= ce did something that the MUD rules disallowed?

This would allow the administrator to select the notifications that he w= ants to provide to the manufacturer.





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





--
M.= Ranganathan

=
--000000000000d806aa0588e228f8-- From nobody Sat May 18 14:25: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 87C9C1200EF for ; Sat, 18 May 2019 14:25:15 -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_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 QoHJ1cckeWVp for ; Sat, 18 May 2019 14:25:13 -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 8D38A12004F for ; Sat, 18 May 2019 14:25:12 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 655933826D; Sat, 18 May 2019 17:24:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 91E3BCA3; Sat, 18 May 2019 17:25:10 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8F7FAC91; Sat, 18 May 2019 17:25:10 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: mud@ietf.org In-Reply-To: References: <17454.1557618668@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: Sat, 18 May 2019 21:25:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >> Section 13.2 says that the MUD-manager should cease processing at th= at 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. > 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 redid the web site, or the company just went under. > 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 numbers, R= IR handles, URLs, ... ... 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. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzgeDYACgkQgItw+93Q 3WUCNwgAhslj4nZC+KADPt20BLlqjVfPGoIRaD1XLmE3AK0HPqbnsaYVnK4bVWLn /wcVWSo5s5NGQfXx7WDh7O5yyiscKonNxWCad8t+fUen9skZEoUgzLzS6mutun6s fnoPZTn90B8q3hwA6Wntmy9kl+/6q/Esi7VLb3DIgswGgHbmdNdCxsv03hmlYzlF GmqplhagddTSvOmQYyNL3E7W1QfT+XyjbRhKOemVLha/TDqBg+bh0n0A9+dCZsiS 4Vfh9CZKHkgaMjH1XL4RU/HhmiEgR5nx4VwHflWYmuIO7nE0ooVbPK4O880otyw9 IF0OnQyrdQo9f3ZCy6SkiqbCb7fNjw== =USFT -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 20 07:07: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 3987E12017D for ; Mon, 20 May 2019 07:07:07 -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_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 WRofURP2_7El for ; Mon, 20 May 2019 07:07:04 -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 AC0DE12012C for ; Mon, 20 May 2019 07:07:04 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id u2so11123557ioc.4 for ; Mon, 20 May 2019 07:07:04 -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=89WlCri2bneWCRr+0eG92UWQTpj7oBUUN0XrfNh9Kb0=; b=tNSw1DZVtltHCe+ZSgxDDHPbDnfV/JIzwzvMkLApcHONKSFMZApWhGswOy1vXIQgjD A2g4yDzuTt7S4LsOJggEaoXdLqAlQWnqo9NzopfmFDLSx9BxwPsjljbNXCXJ0DVWgdCL SE/Mk2JQFH6amfo0UrRyD3FsVQG8hIYWNC6Y7CHo7zY8x7hFeUVi+awugI2QA0bC4RwD oQKgXSy3E7b6TnNcwWoMxjbnKJac40hu4NXeOOL4+DYV7bTsNBZCG4DAoTrxHZLaWoVp KkAaca90sKYmygX4l6rNLLTJJHcKn8IbPfhpBa/oD8kKqnIEP/+mUWjMfZaIdfiUDkjf YXbw== 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=89WlCri2bneWCRr+0eG92UWQTpj7oBUUN0XrfNh9Kb0=; b=QF+VeeWpj6NcPjufC4XmWcFlOz6/pfKkHDw5n6TzeHmjjFlRrrni1fCCc5Rkxc6Nes iX7gFP6OaApiLStjR0X5KO+PpLCGVBGqW7AChJywlpaZ+sVoU1Np+3NIep6vNAKTQ8r5 fI01BqFWtOIo3NvC5U2wSZpK/UbJmfoTGS0gvkEu5wQ34GwtdMYgzBKSc1dEpX1yfAeT wAMk2MrSIIjsuev4aL3X/C/a/Ku3QH1fztxqmyF0Hmu2hDJlHQiMaukTT8O6S6PWIiux K0+Gfpf+qdW31Jf2rVvCSeaml2QIJ899lrjZ6NXEkTEppPRHBaLHetXdrqP4l164QCWs YbmQ== X-Gm-Message-State: APjAAAVaoGxP6bqIOdJoq38rSeQ2B/w7H05KViauZF+0GRxz/uyW3mub /LYFFuvyAXjUzlsGNTj2Gj83xQG5rfIB5alhtBU= X-Google-Smtp-Source: APXvYqx89TKRIuWZrlq6Ldv7eOIJHXyhp38+MJRyIu1agyc/ZoV0BmaPo2r03cFaEP9oxff1jxGPSLyTSiQYAq5BnWw= X-Received: by 2002:a05:6602:214f:: with SMTP id y15mr5174502ioy.102.1558361223703; Mon, 20 May 2019 07:07:03 -0700 (PDT) MIME-Version: 1.0 References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@cisco.com> <30445.1557872022@localhost> In-Reply-To: From: "M. Ranganathan" Date: Mon, 20 May 2019 10:06:26 -0400 Message-ID: To: Michael Richardson Cc: mud@ietf.org, Eliot Lear Content-Type: multipart/alternative; boundary="0000000000002bb48f0589523fe4" Archived-At: Subject: Re: [Mud] Convening MUD calls, + next steps 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, 20 May 2019 14:07:07 -0000 --0000000000002bb48f0589523fe4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are there any standard logging formats to report "misbehavior"? Maybe just use syslog (RFC 3164)? What should the tuning parameters be? I was thinking, frequency of sampling and packet rate estimation. I came across the following which looked interesting: https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guid= e/config/monitor_nsel.html#wp1111174%0A On Tue, May 14, 2019 at 8:22 PM M. Ranganathan wrote: > > > On Tue, May 14, 2019 at 6:13 PM Michael Richardson > wrote: > >> >> Eliot Lear wrote: >> mr> MUD is a series of "ACCEPT" rules followed by an implicit DROP >> rule. So >> mr> how can we know that a specific MUD rule caused a packet to be >> dropped? >> mr> All we know when the packet is dropped (or marked for drop) is >> that NO >> mr> mud rule allowed the packet to proceed. >> >> > On the whole this is generally true. The fact that the packet was >> dropped >> > means that NONE of the accept rules were met, and that=E2=80=99s a= lot of >> information >> > right there. ie, my-controller, same-manufacturer etc didn=E2=80= =99t match, >> or they >> > matched a reject rule. Do others have thoughts there? >> >> But the rules aren't actually fully specific. >> They get instantiated: >> 1) source is the device (by... L2? L3? depends upon implementation) >> 2) destination is an IP, but rule is by name, so how did DNS resolve? >> >> It would be ideal if one could identify packets that would have matched = if >> only the source was different, or the destination was resolved >> differently. >> This requires a bit of fuzzy matching against the drop-log. >> >> That probably accounts for 9 out 10 situations where packets were droppe= d >> that were not really malicious. >> > > If we put a Source MAC/IP classification to activate a notification actio= n > in place of the implied drop, we could notify on the basis of > those classifications. > > The implementation mechanism that is used to classify packets is not so > relevant IMHO. > > What is important is that the packets, get classified and then get droppe= d > because they > misbehave. The MUD rules are stated on the basis of these classifications= . > > So while you cannot state that a specific MUD rule caused a drop, you CAN > state that a particular classification of packets caused a drop. > > Why not use the same classification mechanism that MUD uses to notify tha= t > a packet originated by the > MUD-enabled device did something that the MUD rules disallowed? > > This would allow the administrator to select the notifications that he > wants to provide to the manufacturer. > > > > >> >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> >> > > -- > M. Ranganathan > > --=20 M. Ranganathan --0000000000002bb48f0589523fe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are there any stand= ard logging formats to report "misbehavior"?=C2=A0 Maybe just use= syslog (RFC 3164)?

What should the tuning pa= rameters be? I was thinking, frequency of sampling and packet rate estimati= on.

I came across the following which looked = interesting:

=

On Tue, May 14, 2019 at 8:22 PM M. Ranganathan <mranga@gmail.com> wrote:


On Tue, May 14,= 2019 at 6:13 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Eliot Lear <lear@cis= co.com> wrote:
=C2=A0 =C2=A0 mr> MUD is a series of "ACCEPT" rules followed b= y an implicit DROP rule. So
=C2=A0 =C2=A0 mr> how can we know that a specific MUD rule caused a pack= et to be dropped?
=C2=A0 =C2=A0 mr> All we know when the packet is dropped (or marked for = drop) is that NO
=C2=A0 =C2=A0 mr> mud rule allowed the packet to proceed.

=C2=A0 =C2=A0 > On the whole this is generally true. The fact that the p= acket was dropped
=C2=A0 =C2=A0 > means that NONE of the accept rules were met, and that= =E2=80=99s a lot of information
=C2=A0 =C2=A0 > right there. ie, my-controller, same-manufacturer etc di= dn=E2=80=99t match, or they
=C2=A0 =C2=A0 > matched a reject rule. Do others have thoughts there?
But the rules aren't actually fully specific.
They get instantiated:
=C2=A0 1) source is the device (by... L2? L3? depends upon implementation)<= br> =C2=A0 2) destination is an IP, but rule is by name, so how did DNS resolve= ?

It would be ideal if one could identify packets that would have matched if<= br> only the source was different, or the destination was resolved differently.=
This requires a bit of fuzzy matching against the drop-log.

That probably accounts for 9 out 10 situations where packets were dropped that were not really malicious.

If we p= ut a Source MAC/IP classification to activate a notification action in plac= e of the implied drop, we could notify on the basis of=C2=A0
those classifications.

The implementation mec= hanism that is used to classify packets is not so relevant IMHO.
=
What is important is that the packets, get classified and t= hen get dropped because they
misbehave. The MUD rules are st= ated on the basis of these classifications.

S= o while you cannot state that a specific MUD rule caused a drop, you CAN st= ate that a particular classification of packets caused a drop.

Why not use the same classification mechanism that MUD use= s to notify that a packet originated by the
MUD-enabled devi= ce did something that the MUD rules disallowed?

This would allow the administrator to select the notifications that he w= ants to provide to the manufacturer.





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





--
=
M. Ranganathan

<= /div>


--
M. Ranganathan

<= /div>
--0000000000002bb48f0589523fe4-- From nobody Tue May 21 00:03: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 1393B1201B7 for ; Tue, 21 May 2019 00:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 j6E3V0NMDFwf for ; Tue, 21 May 2019 00:03:26 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 9101512011C for ; Tue, 21 May 2019 00:03:26 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id e19so13105489iob.3 for ; Tue, 21 May 2019 00:03:26 -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=Zif25W80kN9K+Af2EPUZcrgHJpQTz6DpVia2FcyEV/g=; b=Ad/oy+wNTtkbirTgqDS2A8c4bFh0WGLBq4uaUKPjhbZZuPuLk6fnHU23Vr/hgGZ2ty SEHYhf3/PyfNCRT4Qe8D8nii331zkUQwYaoy0LG2F5zGP+fTqrD3Bb05+dQmCI/lichX SzfLE9pmL0yUsbe/GiG9PmmEQgqp0viE7d8g1a29zgc8RO74HTH/s6pyJw3zO8cOzi3K OK/HSJWRTiwBUpRVoL09yRgXUTlgioGEuDRgR77bvugO7qIdpEXlUafUL+/pcWq6qtYh tUd5onNQvYRVTYw5NVEOQAOINOkjllV9SKurs49WUAICqqLbHVTQed5VJEScx2XKI6xM kYig== 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=Zif25W80kN9K+Af2EPUZcrgHJpQTz6DpVia2FcyEV/g=; b=RelPk39tYhVMOsDOKE+pLcJpaCDJ1K/bdKpY3Nd4/jgivfYMKts6VJ7ASW7GtmYgX+ HWswuh76/HmLpqiSjbe8NGP4vBB/lrY+X3T8jCPTXkrAyN9OHlDowCyFP4PsPV84NtB2 RT9imEZp9w7tVJ0mEuje3hoE15UkFcE1qBC+U63EbgKdTa5e1FZYHYknXZViexqV811/ gekdoFKp9Oa0gErheGNPFNmKXPzinhBCaQk6FkTh0GKfLwuK3uXeH/ZEjgGE/y7urBre wV4VzhaezKpVoDRIEv8Ycp4atNq3iWmlhpoTaNtNMfaZAqvDIOTgsbG/N//q+3+xUf5q u8pw== X-Gm-Message-State: APjAAAVq1XIjjXpecoYUbWo+gRCBPMz4zmZYB8xLIrI7elbmKNmDrBxz aEstuingmsnaa21HvPKqGkuVYbkbEvm3BL6T3SY= X-Google-Smtp-Source: APXvYqxVVCAtIKuG3ZYJ31u4LOVQIsqXmsaIhU6HoE1YBPP+8YH+AHwTQQeWzKzH039YeK1zKg2HyleopTO4lbrLHKA= X-Received: by 2002:a5e:cb47:: with SMTP id h7mr42434421iok.69.1558422205907; Tue, 21 May 2019 00:03:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: tirumal reddy Date: Tue, 21 May 2019 12:33:12 +0530 Message-ID: To: "M. Ranganathan" Cc: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000fe465d0589607107" Archived-At: Subject: Re: [Mud] Simplified Quarantine model 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, 21 May 2019 07:03:29 -0000 --000000000000fe465d0589607107 Content-Type: text/plain; charset="UTF-8" How do you identify an attacker is using the victim device's MAC and IP address to send attack traffic (e.g. SYN flood) ? The problem I am facing is victim device can possibly get quarantined based on the attack traffic from the attacker spoofing MAC and IP addresses. Normal traffic from victim's device will end-up getting blocked, and the compromised device in the home can quarantine other normal devices. -Tiru On Tue, 30 Apr 2019 at 21:23, M. Ranganathan wrote: > > Hello, > > I have been reading > > https://tools.ietf.org/html/draft-richardson-shg-un-quarantine-00 > > and > > > https://tools.ietf.org/html/draft-richardson-shg-un-quarantine-00#ref-I-D.richardson-shg-mud-quarantined-access > > I am wondering if these different states defined in the model need to be > defined. > > I would like to collapse these to only two states : > > 1. Normal operation -- a device is operating normally and has not > violated any access rules. > 2. Quarantined - A device that misbehaves (packets originating from the > device cause an access violation) is sent to the quarantined state. A > device is allowed to access those ACEs tagged for quarantined access while > in the quarantined state. > > The system should inform the device administrator under these conditions. > While under quarantine, only the tagged ACE's are allowed i.e. as defined > in : > > > https://tools.ietf.org/html/draft-richardson-shg-un-quarantine-00#ref-I-D.richardson-shg-mud-quarantined-access > > If the device violates its normal ACEs it gets put into the "Quarantine" > state and it remains in that state until the administrator takes whatever > administrative action needs to be taken and changes the state to "Normal". > The manner in which the administrator does this is implementation dependent > (not part of the standard). This can include downloading the firmware > update and flashing it or somehow signaling the device to update itself. > > Any comments on the above? > > Thanks, > > Ranga > > > -- > M. Ranganathan > > -- > You received this message because you are subscribed to the Google Groups > "mud-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mud-discuss+unsubscribe@googlegroups.com. > To post to this group, send email to mud-discuss@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/mud-discuss/CAHiu4JM3oZkXzasiqF9vYzrHFsvDvR446evShQBAXnW46nNXdQ%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > --000000000000fe465d0589607107 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= /table>
On Tue, 30 Apr 2019 at 21:23, M. Ranganathan <mranga@gmail.com> wrote:

Hello,

=
I have been reading

https://tools.ietf.org/html/draft-richardson-shg-un-quarantine-00

and


I am wondering if these different stat= es defined in the model need to be defined.

I= would like to collapse these to only two states :

1. Normal operation --=C2=A0 a device is operating normally and has not vi= olated any access rules.
2. Quarantined=C2=A0 - A device that mis= behaves (packets originating from the device cause an access violation) is = sent to the quarantined state. A device is allowed to access those ACEs tag= ged for quarantined access while in the quarantined state.
<= br>
The system should inform the device administrator under these= conditions. While under quarantine, only the tagged ACE's are allowed = i.e. as defined in :


If the device violates its normal ACEs it = gets put into the "Quarantine" state and it remains in that state= until the administrator takes whatever administrative action needs to be t= aken and changes the state to "Normal".=C2=A0 The manner in which= the administrator does this is implementation dependent (not part of the s= tandard). This can include downloading the firmware update and flashing it = or somehow signaling the device to update itself.

=
Any comments on the above?

Thanks,
=
Ranga


--
=
M. Ranganathan

<= /div>

--
You received this message because you are subscribed to the Google Groups &= quot;mud-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to mud-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to mud-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mud-discuss/CAHiu4JM3oZkXzasiqF9vYzrH= FsvDvR446evShQBAXnW46nNXdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--000000000000fe465d0589607107-- From nobody Tue May 21 09:10: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 6CDD3120145 for ; Tue, 21 May 2019 09:10:03 -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 F2Vuyz50rv-B for ; Tue, 21 May 2019 09:10:01 -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 00470120184 for ; Tue, 21 May 2019 09:09:51 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 914B938277; Tue, 21 May 2019 12:08:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 775DEE8D; Tue, 21 May 2019 12:09:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 74EE1D93; Tue, 21 May 2019 12:09:48 -0400 (EDT) From: Michael Richardson To: mud@ietf.org, "M. Ranganathan" In-Reply-To: References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@cisco.com> <30445.1557872022@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] Convening MUD calls, + next steps 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, 21 May 2019 16:10:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable M. Ranganathan wrote: > Are there any standard logging formats to report "misbehavior"? Maybe= just > use syslog (RFC 3164)? It's a good question! From=20the gateway to... ? what's the place we should report to? Probably the ISP for aggregation. It would be nice if the DHCPv6 included an attribute as to what that was. - ROLIE/MILE - INCH/IODEF I've tried to capture some options in the un-quarantine slides at: https://github.com/CIRALabs/shg-un-quarantine/blob/master/presentations/R= IPE-IoT-Unquarantine-expanded.pdf slide 34. To share details of the event, though, the list includes: - SCAPv2 (rolie) - MISP - TAXI (rolie), STIIX > What should the tuning parameters be? I was thinking, frequency of sa= mpling > and packet rate estimation. what do you mean here? > I came across the following which looked interesting: > https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuratio= n/guide/config/monitor_nsel.html#wp1111174%0A So this uses Netflow, or this uses Syslog? (or some combination) I didn't understand it that well. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzkIswACgkQgItw+93Q 3WWhsAgAjiJ8Wz+nGJVgzihtVASQGUpLjIFLTecTNWXU4X22RaxTL1tvDgBHjlpU eeMjoHiiwjmbKVDz+LHHHDwJ4DX4vw3r/fT6pQrAmSVb5eL4uAUEhykp6eNvvDz0 TLycRWNQcqah//EcevGGUFIVTQNsD9OSi7dM8Ptxl5Im5aRnBF8HoX+wWjbXBCZb 6oFCw80ETzl1DZZ60uXGNQl6xMVMFvv4j0TF9IxPlX9j6hOIF0qsZS2lV9/Yzs7E JNRZJ5wZjGU6yQkCprlZ+s9bmSeFq2KUVOSZRl3FotgQ0f7C+nHm+i8Eu0+8dnKY DKEiVAmYMVxZc/fj6AO/S2WxPHTeIQ== =TsB8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 21 10:19:38 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 B4E33120112 for ; Tue, 21 May 2019 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 h4CoVAiCIej7 for ; Tue, 21 May 2019 10:19:34 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on062b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B3D120086 for ; Tue, 21 May 2019 10:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SBMspASc5UXHQq1CZX3NYBGH2il+xTWaZzVx4XIUSoI=; b=tOTdzPvJQ4+e+cmkqWXOzycTRFZ+HBrugbc2fCwLmje62QB5FjrlWfgwWrNZGHILXd0fZdJY7t5HcYH64hzDK77pZTmqYQHoUEXurAAeq9gLfftPJCIdWrMIPWjQdwI1+Tvs5IrwZH20HzLtLXa2aWqZC6dRJTrdWlwDZQ/Dxqg= Received: from BN7PR06MB6036.namprd06.prod.outlook.com (20.176.31.97) by BN7PR06MB3812.namprd06.prod.outlook.com (52.132.217.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.18; Tue, 21 May 2019 17:19:31 +0000 Received: from BN7PR06MB6036.namprd06.prod.outlook.com ([fe80::907b:f6d6:f4f1:c16f]) by BN7PR06MB6036.namprd06.prod.outlook.com ([fe80::907b:f6d6:f4f1:c16f%2]) with mapi id 15.20.1900.020; Tue, 21 May 2019 17:19:31 +0000 From: Steve Olshansky To: "mud@ietf.org" Thread-Topic: [2] Convening MUD calls, + next steps Thread-Index: AQHVD/lahjCN+xJ+nUiY7yJSer6xTA== Date: Tue, 21 May 2019 17:19:31 +0000 Message-ID: <8733220B-0F01-4D82-8020-23815CF3C40E@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: CY4PR20CA0028.namprd20.prod.outlook.com (2603:10b6:903:cb::14) To BN7PR06MB6036.namprd06.prod.outlook.com (2603:10b6:408:d::33) authentication-results: spf=none (sender IP is ) smtp.mailfrom=olshansky@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: MailMate (1.12.4r5594) x-originating-ip: [173.239.232.141] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74966aed-497e-4dff-912f-08d6de107cbd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:BN7PR06MB3812; x-ms-traffictypediagnostic: BN7PR06MB3812: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39850400004)(136003)(366004)(376002)(396003)(346002)(199004)(189003)(53754006)(316002)(7736002)(66066001)(6512007)(305945005)(33656002)(66476007)(66616009)(66556008)(25786009)(66574012)(1730700003)(2501003)(66446008)(3846002)(6116002)(64756008)(6486002)(73956011)(66946007)(4744005)(6436002)(83716004)(50226002)(2906002)(81156014)(8676002)(81166006)(71190400001)(71200400001)(15974865002)(99936001)(256004)(8936002)(36756003)(486006)(53936002)(5660300002)(68736007)(476003)(5640700003)(6916009)(52116002)(386003)(478600001)(6506007)(26005)(2351001)(186003)(86362001)(2616005)(82746002)(102836004)(99286004)(55236004)(14454004)(18886075002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR06MB3812; H:BN7PR06MB6036.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: F4vXCCsTklSJTi1iz5AjdeMf54R4XQjzwG9s/XYMHpEeyW7yRkq1uPyIpiwjOXIriCkKWewqQQBssz/vItarJEAOyTv6Oq/r99qHgNRaYYMLMZ+nSokgbgNeRETiTNLiSg0nZvVpYO1WKdkcsNNQw86MXtaSYFvUNCebSwvYfuRhHF6FHRrE46y+hkyrcuPv3+ZYRAXFUZO4idCU5ACTfkyIYGd5TdncWqaMqW+BMXU5pyavtBdHA7jlR35/0tG9MKCaakTJuStLefmvJsV0pzTN28+2NNHNE8lOV3doVuZBNAOZEDwIVJVw6oM8q6C82yd6/VZdTwPMA5qf8jYMfnRDCIwYdQNxeeI/lenCz02uZgdMG+SDEsYj/5AMHJrF/PAMyQ+uUw3VNkq1XGOGjiWhMiFUDy033AGxR5IoJVU= Content-Type: multipart/signed; boundary="=_MailMate_525B6A31-9B5A-42FF-A306-0A13967F37C9_="; micalg=pgp-sha1; protocol="application/pgp-signature" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 74966aed-497e-4dff-912f-08d6de107cbd X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 17:19:31.5623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR06MB3812 Archived-At: Subject: [Mud] [2] Convening MUD calls, + next steps 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, 21 May 2019 17:19:37 -0000 --=_MailMate_525B6A31-9B5A-42FF-A306-0A13967F37C9_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All- I am glad to see this great conversation on the list. Bringing this back around to my original question, I am thinking it may b= e time to start some videocalls. In the spirit of conservation of our val= uable time, does monthly still seem like a useful increment? IIRC that wa= s the last suggestion I saw, modulo specific bursty items that would bene= fit from more frequent calls now and then. Or feel free to disagree and let=E2=80=99s just keep going on the list on= ly. Best- Steve -- Steve Olshansky Internet Technology Program Manager Internet Society www.internetsociety.org --=_MailMate_525B6A31-9B5A-42FF-A306-0A13967F37C9_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQFHBAEBAgAxFiEEfMI3gOrhj5ANIVhO4k7j7zvuDccFAlzkMxsTHG9sc2hhbnNr eUBpc29jLm9yZwAKCRDiTuPvO+4Nx4tbB/wIpmglKBGv1BfGMf4WeW0XcnakO9OX OULwz9MsRufbmBRSFg8crH4McN9H9JlDAqQvNAmQp/2+VgT/G61AUoS0RLEEwBKA vUm+IO0o/utmPv8zfxd1kSIitL3uaDER/+pcu7sMU7PXO9DMgB9v+NfoSVJWuEOx Js0cHQiO2vG6RsKxOkQKtYexIDilJSXIMC174ptc9c6l6Z8owpq5jMmcTfroOeBy RGyveVZX+xJX+l0wjr8lnmnEY0ZacG1XxBpry3ip1NJSl+ctVzfwmr7gDAD8ITj8 NVuJAZRDTy/nQjbQKFYXxggs/5vZmDA91pJb6DCH6UYBwZiAJuyKaGVh =pGlp -----END PGP SIGNATURE----- --=_MailMate_525B6A31-9B5A-42FF-A306-0A13967F37C9_=-- From nobody Tue May 21 10:27: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 C3977120181 for ; Tue, 21 May 2019 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 N-cBqDBrAaQM for ; Tue, 21 May 2019 10:27:13 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 7E30912016C for ; Tue, 21 May 2019 10:27:03 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id p2so14616316iol.2 for ; Tue, 21 May 2019 10:27:03 -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=hwF6PKCvsd5BWNwcLQWD44/RS5BMTQbmuVUJn0SbLIE=; b=jkwglJALrYTytzqB72WFL6hgJPjLPBuk4sT6Hva2LkWpvB5Z3lTH+54Wd+dKcMbDxb m2QgVzvlTiDp06IXRGLUMI2uP4MeTvHHHXWsjtacbnrOL/5B7UVp9wxbsBnzRhpARSKN FFC+qKlkpapgW4qy58tZqJb0uXB4MiGomeqAy9DxcycdBYuvnJJcn27q95J3HiyB2Zxw I7wwneIZ4SFDIaUCVIzm2Lqf3PrPTY7Y1Oh18LbWW8OFvNGBR6ESr9XFC5P7DUKkIevI ZYPTCMbUqJHIvOONGt5xRDT/ky8M8yUfJ2kPXD8Bfe7pMMnlIa3930zHXxrzdi4FnCg7 075g== 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=hwF6PKCvsd5BWNwcLQWD44/RS5BMTQbmuVUJn0SbLIE=; b=tOdOP/H5QBWRTNkCUYjgqLF1t5CByaAHwDP4YsWICp72aVaN7HblhUeGwf+Z6Os5mN FaocsKfqfMugrqqft2agNv60r4FknYLkdeSFGS5wuPLzkHnfQK6vHcgsTBWgaWx0cwHO RFL1TTDeeUfwV3Qg1+/XBFTk2jHGLF0X1uobrNgHwt7TMz8s4A79Cyu4MX7JEhSV28YU E/0uu47JQE2yl4IQvlqZhSfpmD0uz2hoFEFTpmeijjXSvhvK3g3+pzndDv3kVgVzB38q X06DQ8S+3yyQWnJyhJ2SsL4tK3nIkTtD/BiCSfsdoQQLlSvygAqWSaw54tGsgpUPAmlC CGag== X-Gm-Message-State: APjAAAVq50zN3blcnquv3TA2cgaWyrSFZTgNhq1emdKjIwBk9OHBO+wp /1ffgaw/vFnaaqCwARXQngPjYNOdh59pDfGbtLxosg== X-Google-Smtp-Source: APXvYqxlFcm9tAtGxlNfUxlxL14imKBIiXO4spPVJgTiYB+6j0jJiLTy5ehTz0hkH7Y0gp+PPO9eeUH5dEAChD2pc9o= X-Received: by 2002:a5e:db08:: with SMTP id q8mr28143813iop.64.1558459622443; Tue, 21 May 2019 10:27:02 -0700 (PDT) MIME-Version: 1.0 References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <19433.1555006746@localhost> <10007.1555379966@localhost> <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@cisco.com> <30445.1557872022@localhost> <15681.1558454988@localhost> In-Reply-To: <15681.1558454988@localhost> From: "M. Ranganathan" Date: Tue, 21 May 2019 13:26:25 -0400 Message-ID: To: Michael Richardson Cc: mud@ietf.org Content-Type: multipart/alternative; boundary="0000000000003150e005896928b6" Archived-At: Subject: Re: [Mud] Convening MUD calls, + next steps 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, 21 May 2019 17:27:16 -0000 --0000000000003150e005896928b6 Content-Type: text/plain; charset="UTF-8" On Tue, May 21, 2019 at 12:09 PM Michael Richardson wrote: > > M. Ranganathan wrote: > > Are there any standard logging formats to report "misbehavior"? > Maybe just > > use syslog (RFC 3164)? > > It's a good question! > From the gateway to... ? what's the place we should report to? > The reporting URL could be specified as a MUD extension (?). Maybe report back to manufacturer so he can have additional information to fix the problem. > Probably the ISP for aggregation. It would be nice if the DHCPv6 included > an attribute as to what that was. > - ROLIE/MILE > - INCH/IODEF > > I've tried to capture some options in the un-quarantine slides at: > > https://github.com/CIRALabs/shg-un-quarantine/blob/master/presentations/RIPE-IoT-Unquarantine-expanded.pdf > slide 34. > > To share details of the event, though, the list includes: > - SCAPv2 (rolie) > - MISP > - TAXI (rolie), STIIX > This is interesting but beyond the scope of what I had in mind. I think to start, a simple event notification mechanism (along with a standardized format for the events) should be a good starting point. (WDYT?) > > What should the tuning parameters be? I was thinking, frequency of > sampling > > and packet rate estimation. > > what do you mean here? > Scenario : A device misbehaves. It is put into quarantine (can only access quarantine ACEs). While it is under quarantine, "Administrator" would like to know statistics about what the device is actually doing under quarantine. How often should this state be reported back to the administrator. One could report back this information periodically. If so, at what frequency. > > I came across the following which looked interesting: > > > > https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/monitor_nsel.html#wp1111174%0A > > So this uses Netflow, or this uses Syslog? (or some combination) > I didn't understand it that well. > I don't understand NSEL that well either (have not played with it -- perhaps Eliot has some insights). In particular, it would not directly apply because there are no DENY ACEs in MUD except for the one if it does not match any previous rule and the TCP direction (which is an implicity deny rule). We would have to suitably modify the semantics. I was thinking we could modify it to carry information about the class of packet based on the source that was dropped. Thanks, > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- M. Ranganathan --0000000000003150e005896928b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 21, 2019 at 12:09 PM Mich= ael Richardson <mcr+ietf@sand= elman.ca> wrote:

M. Ranganathan <mr= anga@gmail.com> wrote:
=C2=A0 =C2=A0 > Are there any standard logging formats to report "m= isbehavior"? Maybe just
=C2=A0 =C2=A0 > use syslog (RFC 3164)?

It's a good question!
>From the gateway to... ? what's the place we should report to?

The reporting URL could be specified as a MUD e= xtension (?). Maybe report back to manufacturer so he can have additional i= nformation to fix the problem.
=C2=A0
Probably the ISP for aggregation.=C2=A0 It would be nice if the DHCPv6 incl= uded
an attribute as to what that was.
=C2=A0 =C2=A0- ROLIE/MILE
=C2=A0 =C2=A0- INCH/IODEF

I've tried to capture some options in the un-quarantine slides at:
=C2=A0 https://github.com/CIRALabs/shg-un-quarantine/blob/master/pres= entations/RIPE-IoT-Unquarantine-expanded.pdf
slide 34.

To share details of the event, though, the list includes:
=C2=A0 =C2=A0 - SCAPv2 (rolie)
=C2=A0 =C2=A0 - MISP
=C2=A0 =C2=A0 - TAXI (rolie), STIIX

Thi= s is interesting but beyond the scope of what I had in mind. I think to sta= rt, a simple event notification mechanism (along with a standardized format= for the events) should be a good starting point. (WDYT?)

=C2=A0 =C2=A0 > What should the tuning parameters be? I was thinking, fr= equency of sampling
=C2=A0 =C2=A0 > and packet rate estimation.

what do you mean here?

Scenario :
=

A device misbehaves. It is put into quarantine (can onl= y access quarantine ACEs).=C2=A0 While it is under quarantine, "Admini= strator" would like to know statistics about what the device is actual= ly doing under quarantine. How often should this state be reported back to = the administrator. One could report back this information periodically. If = so, at what frequency.



=C2=A0 =C2=A0 > I came across the following which looked interesting:
=C2=A0 =C2=A0 > https://www.cisco.com/c/en/us/td/docs/sec= urity/asa/asa82/configuration/guide/config/monitor_nsel.html#wp1111174%0A

So this uses Netflow, or this uses Syslog? (or some combination)
I didn't understand it that well.




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





--
M. Ranganathan

<= /div>
--0000000000003150e005896928b6-- From nobody Sun May 26 18:28:29 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 B570C120221 for ; Sun, 26 May 2019 18:28:28 -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 qM-U0jYAPjvY for ; Sun, 26 May 2019 18:28:27 -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 D93F91201F3 for ; Sun, 26 May 2019 18:28:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CA94E3808A for ; Sun, 26 May 2019 21:27:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 53748F32; Sun, 26 May 2019 21:28:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 521D5B93 for ; Sun, 26 May 2019 21:28:25 -0400 (EDT) From: Michael Richardson To: mud@ietf.org In-Reply-To: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> 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: Mon, 27 May 2019 01:28:29 -0000 --=-=-= Content-Type: text/plain In a private email, it was written: > Okay, I admit I never realized there was an assumption built into MUD that > the MUD enforcement point would be able to spy on DNS queries. I guess I had > assumed one could do reverse DNS, and if that meant some lazy blocking, so be > it. I don't know if it's an assumption built-in to MUD. The assumption in MUD is that a rule can be written in MUD that addresses end points by name, and that if the MUD controller does it's own forward lookup, that it gets the same results as the IoT device. (I wish lookup by reverse worked, and I've long argued that allowing anything on the network without useful reverse DNS is a bad thing, but I've lost that) Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT device) termination by DNS where the result returned depends upon who asks. This is done for geolocation and load balancing reasons. Used to be it was all RR DNS queries with TTL-0 results, but providers realized that this screwed up the caching properties on their servers, and it was better to point a given user/host consistently to an entry server. If the MUD-controller can query the same recursive caching DNS server that the IoT device will likely get the same answer from the cache. So we have a high probability of winning. DNS-o-HTTPS bypasses all that local caching. I believe that we need to write a "Operational Considerations of DNS lookups in MUD files" document. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzrPTkACgkQgItw+93Q 3WUoQAgAsQaKKIc3aIO6x4sk56iHquMP00RdF4fm7k8b+5Nv4cAU8BvjtIKf93yx Y7oSLuzaRswSU0ivDBJcydT8uGthP1l9PxRNYMXAm44yYf39TZUasou8LSt47rRR iZI01bigPbRPSEq3TWdrrTF4TyMVX2u1nafD3EdEok2uy/SBcEh8tl3me0MKYsEX xEEZHD98iaibqMCexxNOHQShfscXruegwEgtv94PGp8B75eobEC/bjdhZ4M03JHC r8AYWnzNZeEz2DX7vtMhjwBLmp/WYCa7oOhIV8S7K/xPSjqZIQ8ST3HA0bfcPrEU 31XkY5UjHsnMrnGQZwxS5zpNCb+x7w== =s3cm -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 27 01:11: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 99F2B12004F for ; Sun, 26 May 2019 23:23: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, 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 header.b=S/SRQiWA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=y9lvHRm6 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 gaVh-ULLBWfG for ; Sun, 26 May 2019 23:23:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FAF12002F for ; Sun, 26 May 2019 23:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2372; q=dns/txt; s=iport; t=1558938213; x=1560147813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KD9VRuppbVhGzJzhrRHCo/RYAcb1/LH0ey5wfpi5GFI=; b=S/SRQiWAc79DGnbmvWnJGKFDizZLknPy0ZmBfO35x7wVR3tt4deWGA6c hFiVwDZGdN7/MgNqdOtTmf/wQSd3PMHvji4CRVIwcZlwcRf5zrVbBFc9i hNGEkilUCkhjFjr6TPx60lmcN0IYav7ipOJzPgIfFtyvIXL3h5zJ2CYfm M=; IronPort-PHdr: =?us-ascii?q?9a23=3A5ohh4hy5FNWIoSvXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIDUDyNtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAAAJgutc/5RdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2lVIAQLKIdaA4RSiieCV5crgS4UgRADVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGBS4J1AoJCIzQJDgEDAQEEAQECAQRtHAyFSgEBAQMBAQEQKAYBASw?= =?us-ascii?q?LAQQLAgEIGB4QJwslAgQOBSKDAAGBagMODwECDJt9AoE4iF+CIIJ5AQEFgke?= =?us-ascii?q?CMxiCDwMGgTQBi1IXgUA/gTgfgh4uPoJhAQGBLgESAQkWgzyCJolDiUyVSAk?= =?us-ascii?q?Cgg2FNY1gG5ZJomYCBAIEBQIOAQEFgU84NjBxcBU7KgGCQYIPDBeDTYUUhT9?= =?us-ascii?q?ygSmKZoJDAQE?= X-IronPort-AV: E=Sophos;i="5.60,518,1549929600"; d="scan'208";a="564848837" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2019 06:23:31 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x4R6NV9g031653 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2019 06:23:31 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 01:23:30 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 02:23:29 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 27 May 2019 01:23:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s7gDkRB9DNybmOmut3UmQoI2bYpbHiEI8jqRe9RDy7k=; b=y9lvHRm6Ubs4pP/uHIiJjbX+4Kcsf6bJfqnrn9X9M7lDEwChw1GDs9329zKHE9Jn0Boxuc+fARh6PGvufNbbiVQqPWXSDyCzmjs7saSWtFanZN6HoU5nGBAoJ2HuUu11gYX1zdiC0zGniMslvEF3cJK9Xntvkr2Ss+CVZxNoQy0= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3656.namprd11.prod.outlook.com (20.178.237.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Mon, 27 May 2019 06:23:28 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56%7]) with mapi id 15.20.1922.021; Mon, 27 May 2019 06:23:28 +0000 From: "Eliot Lear (elear)" To: Michael Richardson CC: "mud@ietf.org" Thread-Topic: [Mud] Unique credentials for devices in a home network Thread-Index: AQHVFCuKU8uy2WzIwUG3dhABmH6VcKZ+gQ1e Date: Mon, 27 May 2019 06:23:28 +0000 Message-ID: <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads>, <8343.1558920505@localhost> In-Reply-To: <8343.1558920505@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:152b:ecc6:f97f:7d49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce5c07ca-46c1-4e34-443a-08d6e26bd508 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3656; x-ms-traffictypediagnostic: BYAPR11MB3656: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(376002)(346002)(396003)(189003)(199004)(64756008)(2906002)(66946007)(66476007)(66556008)(73956011)(6436002)(66446008)(71200400001)(5660300002)(6486002)(36756003)(6116002)(6512007)(305945005)(7736002)(6306002)(91956017)(14444005)(256004)(71190400001)(33656002)(83716004)(46003)(11346002)(446003)(186003)(2616005)(316002)(476003)(486006)(102836004)(6506007)(53546011)(478600001)(86362001)(4326008)(966005)(14454004)(76176011)(76116006)(99286004)(6246003)(8936002)(229853002)(82746002)(8676002)(81166006)(81156014)(68736007)(25786009)(53936002)(222643001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3656; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wjzmtu0DEiHe8gQnm087btDnNP2YG3oGlEeonSCMi7dYovFm9wz0ljO+a0PW922RTGLjqUvbxtc8Z/w+LdMwCtWqmCeSBfxGxLteKV/75c/FINuAE7dsrcxRYEmrjiBWVkDRp8G6+gut048Q5aGzPr/DEddpmaAvWjbSOe8PdX0lfebVWHNSZKY2s+BjEhxiA1Y9DGLGoCNN4HY3kBgfhKffIlMDWlpYbkzWIdUSJm4/hLfpXwE/4bqOzou1KHmfCZyFd8R8PL5TI3CgsOBuAwZFAA99qamy7tUss5hcCs4OeC/x9O/DwEDKZA1I9t4Zf/1kCy57j5s3EMFB93T7tXV0B+2JbpMIZ8tfkZnJhRNx9tsg8gVieAbVJ8gmMjEEp4d8ETLSHzvYW2NPaHplAgtyfIIuzaymRKC690HFzQU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ce5c07ca-46c1-4e34-443a-08d6e26bd508 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2019 06:23:28.2051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: elear@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3656 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: X-Mailman-Approved-At: Mon, 27 May 2019 01:10:59 -0700 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: Mon, 27 May 2019 06:23:36 -0000 To add to what Michael said the requirement is for consistency between the = client and the enforcement point. There are several ways to do that with re= gard to DNS names. One is to snoop DNS. Another is for the resolver to coor= dinate with the enforcement point. Arguably the latter is the better approa= ch but requires more work.=20 The one mechanism that will certainly not work is DOH when the end device i= gnores to resolve are handed to it by DHCP. Eliot > On May 27, 2019, at 03:28, Michael Richardson wro= te: >=20 >=20 > In a private email, it was written: >> Okay, I admit I never realized there was an assumption built into MUD th= at >> the MUD enforcement point would be able to spy on DNS queries. I guess I= had >> assumed one could do reverse DNS, and if that meant some lazy blocking, = so be >> it. >=20 > I don't know if it's an assumption built-in to MUD. >=20 > The assumption in MUD is that a rule can be written in MUD that addresses > end points by name, and that if the MUD controller does it's own forward > lookup, that it gets the same results as the IoT device. > (I wish lookup by reverse worked, and I've long argued that allowing anyt= hing > on the network without useful reverse DNS is a bad thing, but I've lost t= hat) >=20 > Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT device= ) > termination by DNS where the result returned depends upon who asks. This= is > done for geolocation and load balancing reasons. Used to be it was all > RR DNS queries with TTL-0 results, but providers realized that this screw= ed > up the caching properties on their servers, and it was better to point a > given user/host consistently to an entry server. >=20 > If the MUD-controller can query the same recursive caching DNS server tha= t the > IoT device will likely get the same answer from the cache. So we have a = high > probability of winning. >=20 > DNS-o-HTTPS bypasses all that local caching. >=20 > I believe that we need to write a "Operational Considerations of DNS look= ups > in MUD files" document. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > --=20 > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud From nobody Mon May 27 02:55:27 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 2234812004E for ; Mon, 27 May 2019 02:55: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 y5DVcHXjOXzO for ; Mon, 27 May 2019 02:55:22 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 C428412004B for ; Mon, 27 May 2019 02:55:22 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id m3so25996761itl.1 for ; Mon, 27 May 2019 02:55:22 -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=JMrsnOLys7JDT0OaNsTYhsgGJCljJTPXopsIvDHz+IU=; b=DhOJggknK7yJ2CZcUwKs4r1psY6Bwsgj4Sj2z9nQoElx+jFqPyBWsrzUfG0rvUfus7 /icR+eeGQXuWxGkLo6BTnXshKp4V4QZUuxWDZcwFkiZZikcm9hfmNKFvyX+mwHzZd9Mv Lq3ZUXzynfYtjHEwooU5h6ccPpaF5XzKw8LnZdkwnAtY4bewCHUuMKAf1TIWlfqI9c6s ZgNUZA3spyf8JWoY/QHRhMcyMFs2pw2E5wQOIYrDj2rZo+bLyyMmBm41H4/wNTdrNW0P wdg1En5+TCmDSvebfl4n1lmmuCj+bn3iMkiMj5OWcOZdVhQ3+b8OM+oBWm5Z6QAXLZe8 +mfQ== 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=JMrsnOLys7JDT0OaNsTYhsgGJCljJTPXopsIvDHz+IU=; b=i5BnMEqgdxHEpVHTpJW75M3IZbSIaBXdOUTOr+rf7RxST1fA/e8FLCgIsXTSutloqO lJlsJTb4nS0vkug3bqlL8TnebMJkqNSjsXFN3gQffQ2mYs257lygqOoa5jeBvptIIiTf l5xiNeIBk26fJ9LHQFp9CU2yWXEze7lOReuhHu82yioCWAcUt2+uC0qjMtgrGFLrxTo2 7iGQ6oB0NmWRkSIwJOnNyilMOCVK7IpGousioqCYAQBNudzL5Uy0zHhrngxgyNG8TGoO iQ8rtpkPLxEenLEVoauuEZrpHAi7RtOHPWL8/cIwQ5QnqC4FY9EOZZtJI3cSE0o2ooro 7qmg== X-Gm-Message-State: APjAAAW8kEpXCt8O5FGg2K+VbqYNd4BCE/uMypBuNF9MY62z+vgXMMpS jKGyqDC7GNquQRWEBCYS32LQlX62Bxa8Y/TWX8k= X-Google-Smtp-Source: APXvYqwv2rfKqvX7flDRxGD/bb5mYIFTuiV/pY4Dovi2sWc8Ju2Hut84j2VdoI0EW8XJB1SNBAqdNLMFB8t20Ebmmaw= X-Received: by 2002:a24:798a:: with SMTP id z132mr26745115itc.101.1558950921953; Mon, 27 May 2019 02:55:21 -0700 (PDT) MIME-Version: 1.0 References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> In-Reply-To: <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> From: tirumal reddy Date: Mon, 27 May 2019 15:25:10 +0530 Message-ID: To: "Eliot Lear (elear)" Cc: Michael Richardson , "mud@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ece94c0589db8bac" 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: Mon, 27 May 2019 09:55:25 -0000 --000000000000ece94c0589db8bac Content-Type: text/plain; charset="UTF-8" If multiple domains are hosted on the same IP address and the IoT device uses DOH, the enforcement point will not know the domain the IoT device is visiting. Further, MUD controller may not even know the DOH server used by the IoT device. Google supports domain fronting for its DOH server (see https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y). Cheers, -Tiru On Mon, 27 May 2019 at 13:41, Eliot Lear (elear) wrote: > To add to what Michael said the requirement is for consistency between the > client and the enforcement point. There are several ways to do that with > regard to DNS names. One is to snoop DNS. Another is for the resolver to > coordinate with the enforcement point. Arguably the latter is the better > approach but requires more work. > > The one mechanism that will certainly not work is DOH when the end device > ignores to resolve are handed to it by DHCP. > > Eliot > > > On May 27, 2019, at 03:28, Michael Richardson > wrote: > > > > > > In a private email, it was written: > >> Okay, I admit I never realized there was an assumption built into MUD > that > >> the MUD enforcement point would be able to spy on DNS queries. I guess > I had > >> assumed one could do reverse DNS, and if that meant some lazy blocking, > so be > >> it. > > > > I don't know if it's an assumption built-in to MUD. > > > > The assumption in MUD is that a rule can be written in MUD that addresses > > end points by name, and that if the MUD controller does it's own forward > > lookup, that it gets the same results as the IoT device. > > (I wish lookup by reverse worked, and I've long argued that allowing > anything > > on the network without useful reverse DNS is a bad thing, but I've lost > that) > > > > Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT > device) > > termination by DNS where the result returned depends upon who asks. > This is > > done for geolocation and load balancing reasons. Used to be it was all > > RR DNS queries with TTL-0 results, but providers realized that this > screwed > > up the caching properties on their servers, and it was better to point a > > given user/host consistently to an entry server. > > > > If the MUD-controller can query the same recursive caching DNS server > that the > > IoT device will likely get the same answer from the cache. So we have a > high > > probability of winning. > > > > DNS-o-HTTPS bypasses all that local caching. > > > > I believe that we need to write a "Operational Considerations of DNS > lookups > > in MUD files" document. > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > -- > > Mud mailing list > > Mud@ietf.org > > https://www.ietf.org/mailman/listinfo/mud > > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > --000000000000ece94c0589db8bac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If multiple domains are hosted on the sam= e IP address and the IoT device uses DOH, the enforcement point will=C2=A0n= ot know the domain the IoT device is visiting.=C2=A0Further, MUD controller= may not even know the=C2=A0DOH server used by the IoT device.=C2=A0
<= div dir=3D"ltr">
Google supports domain fronting = for=C2=A0its DOH server (see https://mailarchive.ietf.org/arch/msg/d= oh/95MtwTSUxcSVCUCxjaBhpx0m98Y).

Cheers,
-Tiru

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, 27 May 2019 at 13:41, Eliot Le= ar (elear) <elear@cisco.com> w= rote:
To add to = what Michael said the requirement is for consistency between the client and= the enforcement point. There are several ways to do that with regard to DN= S names. One is to snoop DNS. Another is for the resolver to coordinate wit= h the enforcement point. Arguably the latter is the better approach but req= uires more work.

The one mechanism that will certainly not work is DOH when the end device i= gnores to resolve are handed to it by DHCP.

Eliot

> On May 27, 2019, at 03:28, Michael Richardson <mcr+ietf@sandelman.ca> wrot= e:
>
>
> In a private email, it was written:
>> Okay, I admit I never realized there was an assumption built into = MUD that
>> the MUD enforcement point would be able to spy on DNS queries. I g= uess I had
>> assumed one could do reverse DNS, and if that meant some lazy bloc= king, so be
>> it.
>
> I don't know if it's an assumption built-in to MUD.
>
> The assumption in MUD is that a rule can be written in MUD that addres= ses
> end points by name, and that if the MUD controller does it's own f= orward
> lookup, that it gets the same results as the IoT device.
> (I wish lookup by reverse worked, and I've long argued that allowi= ng anything
> on the network without useful reverse DNS is a bad thing, but I've= lost that)
>
> Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT dev= ice)
> termination by DNS where the result returned depends upon who asks.=C2= =A0 This is
> done for geolocation and load balancing reasons.=C2=A0 Used to be it w= as all
> RR DNS queries with TTL-0 results, but providers realized that this sc= rewed
> up the caching properties on their servers, and it was better to point= a
> given user/host consistently to an entry server.
>
> If the MUD-controller can query the same recursive caching DNS server = that the
> IoT device will likely get the same answer from the cache.=C2=A0 So we= have a high
> probability of winning.
>
> DNS-o-HTTPS bypasses all that local caching.
>
> I believe that we need to write a "Operational Considerations of = DNS lookups
> in MUD files" document.
>
> --
> 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

--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud
--000000000000ece94c0589db8bac-- From nobody Mon May 27 03:04: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 7A68712011A for ; Mon, 27 May 2019 03:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aOpKf3LW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jXAUU+Ru 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 l5GModx2sRZJ for ; Mon, 27 May 2019 03:04:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1181312004C for ; Mon, 27 May 2019 03:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12141; q=dns/txt; s=iport; t=1558951467; x=1560161067; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WeR8kTJz5bseiJ6mt9bGGzjX7X002h9H+CONRWfsKz8=; b=aOpKf3LWWhnMaeh+L8+goTy+QQqIL84p6evxPE7MnPFigLSypIjtRaN9 CzzZrPTWQnQYx9ntCBHyG9aa6Q9gLIFKMFCmWXDF5xTHXsYjKn/GnS8+L S7LShvU6vyDk8d6k0htKr0dV2gO2ZxzIpKpN5PenHGURijQCBRZtXq1kq Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AT3bwuBwsodjUJ/HXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIDUDyNtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAACHtetc/4kNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2lVIAQLKIQTg0cDhFKKJ4JXiUGJGoRQgS4UgRADVAk?= =?us-ascii?q?BAQEMAQEYAQoKAgEBgUuCdQIXgjwjNAkOAQMBAQQBAQIBBG0cDIVKAQEBAwE?= =?us-ascii?q?BARARHQEBLAsBBAsCAQgYJwMCAgIfBgsUEQIEDgUigwABgR1NAw4PAQIMA5w?= =?us-ascii?q?iAoE4iF9xgS+CeQEBBYEyAYEUgjQNC4IPAwaBNAGLUheBQD+BOB+CHi4+ghp?= =?us-ascii?q?HAQECgSwBEgEJQ4JdMoImiUOESYRjIJULPQkCgg2FNX+IfYNkG5ZJk3CBWo0?= =?us-ascii?q?cAgQCBAUCDgEBBYFPODYwcXAVOyoBgkGCDwwXg02FFIU/coEpinOCQwEB?= X-IronPort-AV: E=Sophos;i="5.60,518,1549929600"; d="scan'208,217";a="565293778" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2019 10:04:26 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x4RA4QsQ030120 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2019 10:04:26 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 05:04:25 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 05:04:24 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 27 May 2019 05:04:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WeR8kTJz5bseiJ6mt9bGGzjX7X002h9H+CONRWfsKz8=; b=jXAUU+RuUWp+7zf8epbkCigvQC0nigoEddBppKM1jp4/TC130OnGBa8ee5aFSubqyCXCc8h0UR8/+W3O+Lay5PGFqNGoSxi/nOVZ8a0T0996vLWSAjZaRjSqbPgqWnUTVj2urXv12AZjpeLTNSj/2BjqWDa8rT0PDpNs6ulLIYQ= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3269.namprd11.prod.outlook.com (20.177.185.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Mon, 27 May 2019 10:04:23 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56%7]) with mapi id 15.20.1922.021; Mon, 27 May 2019 10:04:23 +0000 From: "Eliot Lear (elear)" To: tirumal reddy CC: Michael Richardson , "mud@ietf.org" Thread-Topic: [Mud] Unique credentials for devices in a home network Thread-Index: AQHVFCuKU8uy2WzIwUG3dhABmH6VcKZ+gQ1egAA7JgCAAAKUrw== Date: Mon, 27 May 2019 10:04:23 +0000 Message-ID: <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:152b:ecc6:f97f:7d49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55a6c07e-5c4e-492f-390f-08d6e28ab1e5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3269; x-ms-traffictypediagnostic: BYAPR11MB3269: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(396003)(136003)(189003)(199004)(14454004)(53546011)(236005)(6916009)(5660300002)(53936002)(4326008)(6486002)(6506007)(6436002)(6512007)(6306002)(46003)(64756008)(66446008)(66946007)(76116006)(91956017)(54896002)(102836004)(66476007)(73956011)(68736007)(76176011)(66556008)(316002)(86362001)(486006)(11346002)(476003)(2616005)(81156014)(99286004)(82746002)(1411001)(14444005)(229853002)(25786009)(6116002)(256004)(81166006)(966005)(446003)(8936002)(54906003)(186003)(6246003)(36756003)(7736002)(2906002)(33656002)(83716004)(478600001)(8676002)(606006)(71190400001)(71200400001)(222643001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3269; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /OGAMGGWljXbYfDOW51/BRw7cWL6vCN0j5I60rXkgobq5IiFpbQAY6lwib+1hWl0aNnPF82LQ77c6lFduzKtle/uumTU21qWEH0MgzBwiz7HZ1ilB/BUCWk2g+srvuCVOWtsxWOqVh7VF4GgsYHrKiilhufm+AZYjWqV1/wTLF4ZFZbNQk1S4JQ5Owk4Zc5k15OMYOIIZnUVLKlsBCScCz+QlhOZLJQXcBg/2RoA/f/XIdtwyp0KZrkprPOiMJ0dCA2iySlmA1wufSp9fWNOyK+KrK1U6YTR5lg1Wam32Rh8HAmI/wZ8G4eHdYzWpWJuFQQQEJl8s1KDVbrgCs62GpVunARj3aFvNqdvylG3/OzUv4ka+MVkas9vn0+obsj8Beqaj8oOAgqBZ8rEPHSt5g4VcpE3qHV6Uhcm2edQ8rY= Content-Type: multipart/alternative; boundary="_000_9BF2E606D26241F5905CB7ECCBBB42FFciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 55a6c07e-5c4e-492f-390f-08d6e28ab1e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2019 10:04:23.5828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: elear@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3269 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: alln-core-4.cisco.com 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: Mon, 27 May 2019 10:04:30 -0000 --_000_9BF2E606D26241F5905CB7ECCBBB42FFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWJzb2x1dGVseSB0cnVlLiAgQW5kIHRoYXQgbWF0dGVycyBpZiB0aGVyZSBpcyBhIHZhc3QgcXVh bnRpdHkgb2YgY3JhcCBvbiB0aG9zZSBJUHMuICBXb3J0aCBrZWVwaW5nIGluIG1pbmQuIEJ1dCB0 aGlzIGlzbuKAmXQgZG8gbXVjaCBhIE1VRCBwcm9ibGVtIGFzIG1vcmUgb2YgYSBHZW5lcmFsIGh5 Z2llbmUgbWF0dGVyLiAgWW91IGFyZSBsaWtlbHkgdG8gYmxvY2sgSVBzIHdpdGggZ2FyYmFnZSBv biB0aGVtIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBNVUQgaXMgaW4gcGxheS4NCg0KRWxpb3QNCg0K T24gTWF5IDI3LCAyMDE5LCBhdCAxMTo1NiwgdGlydW1hbCByZWRkeSA8a29uZHRpckBnbWFpbC5j b208bWFpbHRvOmtvbmR0aXJAZ21haWwuY29tPj4gd3JvdGU6DQoNCklmIG11bHRpcGxlIGRvbWFp bnMgYXJlIGhvc3RlZCBvbiB0aGUgc2FtZSBJUCBhZGRyZXNzIGFuZCB0aGUgSW9UIGRldmljZSB1 c2VzIERPSCwgdGhlIGVuZm9yY2VtZW50IHBvaW50IHdpbGwgbm90IGtub3cgdGhlIGRvbWFpbiB0 aGUgSW9UIGRldmljZSBpcyB2aXNpdGluZy4gRnVydGhlciwgTVVEIGNvbnRyb2xsZXIgbWF5IG5v dCBldmVuIGtub3cgdGhlIERPSCBzZXJ2ZXIgdXNlZCBieSB0aGUgSW9UIGRldmljZS4NCg0KR29v Z2xlIHN1cHBvcnRzIGRvbWFpbiBmcm9udGluZyBmb3IgaXRzIERPSCBzZXJ2ZXIgKHNlZSBodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RvaC85NU10d1RTVXhjU1ZDVUN4amFC aHB4MG05OFkpLg0KDQpDaGVlcnMsDQotVGlydQ0KDQpPbiBNb24sIDI3IE1heSAyMDE5IGF0IDEz OjQxLCBFbGlvdCBMZWFyIChlbGVhcikgPGVsZWFyQGNpc2NvLmNvbTxtYWlsdG86ZWxlYXJAY2lz Y28uY29tPj4gd3JvdGU6DQpUbyBhZGQgdG8gd2hhdCBNaWNoYWVsIHNhaWQgdGhlIHJlcXVpcmVt ZW50IGlzIGZvciBjb25zaXN0ZW5jeSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBlbmZvcmNl bWVudCBwb2ludC4gVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBkbyB0aGF0IHdpdGggcmVnYXJk IHRvIEROUyBuYW1lcy4gT25lIGlzIHRvIHNub29wIEROUy4gQW5vdGhlciBpcyBmb3IgdGhlIHJl c29sdmVyIHRvIGNvb3JkaW5hdGUgd2l0aCB0aGUgZW5mb3JjZW1lbnQgcG9pbnQuIEFyZ3VhYmx5 IHRoZSBsYXR0ZXIgaXMgdGhlIGJldHRlciBhcHByb2FjaCBidXQgcmVxdWlyZXMgbW9yZSB3b3Jr Lg0KDQpUaGUgb25lIG1lY2hhbmlzbSB0aGF0IHdpbGwgY2VydGFpbmx5IG5vdCB3b3JrIGlzIERP SCB3aGVuIHRoZSBlbmQgZGV2aWNlIGlnbm9yZXMgdG8gcmVzb2x2ZSBhcmUgaGFuZGVkIHRvIGl0 IGJ5IERIQ1AuDQoNCkVsaW90DQoNCj4gT24gTWF5IDI3LCAyMDE5LCBhdCAwMzoyOCwgTWljaGFl bCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jciUyQmlldGZAc2Fu ZGVsbWFuLmNhPj4gd3JvdGU6DQo+DQo+DQo+IEluIGEgcHJpdmF0ZSBlbWFpbCwgaXQgd2FzIHdy aXR0ZW46DQo+PiBPa2F5LCBJIGFkbWl0IEkgbmV2ZXIgcmVhbGl6ZWQgdGhlcmUgd2FzIGFuIGFz c3VtcHRpb24gYnVpbHQgaW50byBNVUQgdGhhdA0KPj4gdGhlIE1VRCBlbmZvcmNlbWVudCBwb2lu dCB3b3VsZCBiZSBhYmxlIHRvIHNweSBvbiBETlMgcXVlcmllcy4gSSBndWVzcyBJIGhhZA0KPj4g YXNzdW1lZCBvbmUgY291bGQgZG8gcmV2ZXJzZSBETlMsIGFuZCBpZiB0aGF0IG1lYW50IHNvbWUg bGF6eSBibG9ja2luZywgc28gYmUNCj4+IGl0Lg0KPg0KPiBJIGRvbid0IGtub3cgaWYgaXQncyBh biBhc3N1bXB0aW9uIGJ1aWx0LWluIHRvIE1VRC4NCj4NCj4gVGhlIGFzc3VtcHRpb24gaW4gTVVE IGlzIHRoYXQgYSBydWxlIGNhbiBiZSB3cml0dGVuIGluIE1VRCB0aGF0IGFkZHJlc3Nlcw0KPiBl bmQgcG9pbnRzIGJ5IG5hbWUsIGFuZCB0aGF0IGlmIHRoZSBNVUQgY29udHJvbGxlciBkb2VzIGl0 J3Mgb3duIGZvcndhcmQNCj4gbG9va3VwLCB0aGF0IGl0IGdldHMgdGhlIHNhbWUgcmVzdWx0cyBh cyB0aGUgSW9UIGRldmljZS4NCj4gKEkgd2lzaCBsb29rdXAgYnkgcmV2ZXJzZSB3b3JrZWQsIGFu ZCBJJ3ZlIGxvbmcgYXJndWVkIHRoYXQgYWxsb3dpbmcgYW55dGhpbmcNCj4gb24gdGhlIG5ldHdv cmsgd2l0aG91dCB1c2VmdWwgcmV2ZXJzZSBETlMgaXMgYSBiYWQgdGhpbmcsIGJ1dCBJJ3ZlIGxv c3QgdGhhdCkNCj4NCj4gR29vZ2xlLCBBa2FtYWksIEZhY2Vib29rLCBBbWF6b24sIEF6dXJlLCBl dGMuIGFsbCBwcm92aWRlIGZvciAoSW9UIGRldmljZSkNCj4gdGVybWluYXRpb24gYnkgRE5TIHdo ZXJlIHRoZSByZXN1bHQgcmV0dXJuZWQgZGVwZW5kcyB1cG9uIHdobyBhc2tzLiAgVGhpcyBpcw0K PiBkb25lIGZvciBnZW9sb2NhdGlvbiBhbmQgbG9hZCBiYWxhbmNpbmcgcmVhc29ucy4gIFVzZWQg dG8gYmUgaXQgd2FzIGFsbA0KPiBSUiBETlMgcXVlcmllcyB3aXRoIFRUTC0wIHJlc3VsdHMsIGJ1 dCBwcm92aWRlcnMgcmVhbGl6ZWQgdGhhdCB0aGlzIHNjcmV3ZWQNCj4gdXAgdGhlIGNhY2hpbmcg cHJvcGVydGllcyBvbiB0aGVpciBzZXJ2ZXJzLCBhbmQgaXQgd2FzIGJldHRlciB0byBwb2ludCBh DQo+IGdpdmVuIHVzZXIvaG9zdCBjb25zaXN0ZW50bHkgdG8gYW4gZW50cnkgc2VydmVyLg0KPg0K PiBJZiB0aGUgTVVELWNvbnRyb2xsZXIgY2FuIHF1ZXJ5IHRoZSBzYW1lIHJlY3Vyc2l2ZSBjYWNo aW5nIEROUyBzZXJ2ZXIgdGhhdCB0aGUNCj4gSW9UIGRldmljZSB3aWxsIGxpa2VseSBnZXQgdGhl IHNhbWUgYW5zd2VyIGZyb20gdGhlIGNhY2hlLiAgU28gd2UgaGF2ZSBhIGhpZ2gNCj4gcHJvYmFi aWxpdHkgb2Ygd2lubmluZy4NCj4NCj4gRE5TLW8tSFRUUFMgYnlwYXNzZXMgYWxsIHRoYXQgbG9j YWwgY2FjaGluZy4NCj4NCj4gSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCB0byB3cml0ZSBhICJPcGVy YXRpb25hbCBDb25zaWRlcmF0aW9ucyBvZiBETlMgbG9va3Vwcw0KPiBpbiBNVUQgZmlsZXMiIGRv Y3VtZW50Lg0KPg0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1h bi5jYTxtYWlsdG86bWNyJTJCSUVURkBzYW5kZWxtYW4uY2E+PiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4NCj4NCj4NCj4gLS0NCj4gTXVk IG1haWxpbmcgbGlzdA0KPiBNdWRAaWV0Zi5vcmc8bWFpbHRvOk11ZEBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQNCg0KLS0NCk11ZCBtYWlsaW5n IGxpc3QNCk11ZEBpZXRmLm9yZzxtYWlsdG86TXVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQNCi0tDQpNdWQgbWFpbGluZyBsaXN0DQpNdWRAaWV0 Zi5vcmc8bWFpbHRvOk11ZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXVkDQo= --_000_9BF2E606D26241F5905CB7ECCBBB42FFciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpB YnNvbHV0ZWx5IHRydWUuICZuYnNwO0FuZCB0aGF0IG1hdHRlcnMgaWYgdGhlcmUgaXMgYSB2YXN0 IHF1YW50aXR5IG9mIGNyYXAgb24gdGhvc2UgSVBzLiAmbmJzcDtXb3J0aCBrZWVwaW5nIGluIG1p bmQuIEJ1dCB0aGlzIGlzbuKAmXQgZG8gbXVjaCBhIE1VRCBwcm9ibGVtIGFzIG1vcmUgb2YgYSBH ZW5lcmFsIGh5Z2llbmUgbWF0dGVyLiAmbmJzcDtZb3UgYXJlIGxpa2VseSB0byBibG9jayBJUHMg d2l0aCBnYXJiYWdlIG9uIHRoZW0gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIE1VRA0KIGlzIGluIHBs YXkuJm5ic3A7DQo8ZGl2Pjxicj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSIgZGlyPSJs dHIiPkVsaW90PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQpPbiBNYXkgMjcsIDIwMTksIGF0 IDExOjU2LCB0aXJ1bWFsIHJlZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86a29uZHRpckBnbWFpbC5j b20iPmtvbmR0aXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGRpcj0ibHRyIj5JZiBtdWx0aXBsZSBkb21haW5zIGFyZSBob3N0ZWQgb24gdGhlIHNh bWUgSVAgYWRkcmVzcyBhbmQgdGhlIElvVCBkZXZpY2UgdXNlcyBET0gsIHRoZSBlbmZvcmNlbWVu dCBwb2ludCB3aWxsJm5ic3A7bm90IGtub3cgdGhlIGRvbWFpbiB0aGUgSW9UIGRldmljZSBpcyB2 aXNpdGluZy4mbmJzcDtGdXJ0aGVyLCBNVUQgY29udHJvbGxlciBtYXkgbm90IGV2ZW4ga25vdyB0 aGUmbmJzcDtET0ggc2VydmVyIHVzZWQgYnkgdGhlIElvVCBkZXZpY2UuJm5ic3A7PC9kaXY+DQo8 ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPkdvb2dsZSBzdXBwb3J0 cyBkb21haW4gZnJvbnRpbmcgZm9yJm5ic3A7aXRzIERPSCBzZXJ2ZXIgKHNlZSA8YSBocmVmPSJo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RvaC85NU10d1RTVXhjU1ZDVUN4 amFCaHB4MG05OFkiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kb2gv OTVNdHdUU1V4Y1NWQ1VDeGphQmhweDBtOThZPC9hPikuPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj4tVGlydTwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJs dHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIDI3IE1heSAyMDE5IGF0IDEzOjQxLCBFbGlv dCBMZWFyIChlbGVhcikgJmx0OzxhIGhyZWY9Im1haWx0bzplbGVhckBjaXNjby5jb20iPmVsZWFy QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KVG8gYWRkIHRv IHdoYXQgTWljaGFlbCBzYWlkIHRoZSByZXF1aXJlbWVudCBpcyBmb3IgY29uc2lzdGVuY3kgYmV0 d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgZW5mb3JjZW1lbnQgcG9pbnQuIFRoZXJlIGFyZSBzZXZl cmFsIHdheXMgdG8gZG8gdGhhdCB3aXRoIHJlZ2FyZCB0byBETlMgbmFtZXMuIE9uZSBpcyB0byBz bm9vcCBETlMuIEFub3RoZXIgaXMgZm9yIHRoZSByZXNvbHZlciB0byBjb29yZGluYXRlIHdpdGgg dGhlIGVuZm9yY2VtZW50IHBvaW50Lg0KIEFyZ3VhYmx5IHRoZSBsYXR0ZXIgaXMgdGhlIGJldHRl ciBhcHByb2FjaCBidXQgcmVxdWlyZXMgbW9yZSB3b3JrLiA8YnI+DQo8YnI+DQpUaGUgb25lIG1l Y2hhbmlzbSB0aGF0IHdpbGwgY2VydGFpbmx5IG5vdCB3b3JrIGlzIERPSCB3aGVuIHRoZSBlbmQg ZGV2aWNlIGlnbm9yZXMgdG8gcmVzb2x2ZSBhcmUgaGFuZGVkIHRvIGl0IGJ5IERIQ1AuPGJyPg0K PGJyPg0KRWxpb3Q8YnI+DQo8YnI+DQomZ3Q7IE9uIE1heSAyNywgMjAxOSwgYXQgMDM6MjgsIE1p Y2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciUyQmlldGZAc2FuZGVsbWFu LmNhIiB0YXJnZXQ9Il9ibGFuayI+bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIGEgcHJpdmF0ZSBlbWFpbCwg aXQgd2FzIHdyaXR0ZW46PGJyPg0KJmd0OyZndDsgT2theSwgSSBhZG1pdCBJIG5ldmVyIHJlYWxp emVkIHRoZXJlIHdhcyBhbiBhc3N1bXB0aW9uIGJ1aWx0IGludG8gTVVEIHRoYXQ8YnI+DQomZ3Q7 Jmd0OyB0aGUgTVVEIGVuZm9yY2VtZW50IHBvaW50IHdvdWxkIGJlIGFibGUgdG8gc3B5IG9uIERO UyBxdWVyaWVzLiBJIGd1ZXNzIEkgaGFkPGJyPg0KJmd0OyZndDsgYXNzdW1lZCBvbmUgY291bGQg ZG8gcmV2ZXJzZSBETlMsIGFuZCBpZiB0aGF0IG1lYW50IHNvbWUgbGF6eSBibG9ja2luZywgc28g YmU8YnI+DQomZ3Q7Jmd0OyBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBkb24ndCBrbm93IGlm IGl0J3MgYW4gYXNzdW1wdGlvbiBidWlsdC1pbiB0byBNVUQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoZSBhc3N1bXB0aW9uIGluIE1VRCBpcyB0aGF0IGEgcnVsZSBjYW4gYmUgd3JpdHRlbiBpbiBN VUQgdGhhdCBhZGRyZXNzZXM8YnI+DQomZ3Q7IGVuZCBwb2ludHMgYnkgbmFtZSwgYW5kIHRoYXQg aWYgdGhlIE1VRCBjb250cm9sbGVyIGRvZXMgaXQncyBvd24gZm9yd2FyZDxicj4NCiZndDsgbG9v a3VwLCB0aGF0IGl0IGdldHMgdGhlIHNhbWUgcmVzdWx0cyBhcyB0aGUgSW9UIGRldmljZS48YnI+ DQomZ3Q7IChJIHdpc2ggbG9va3VwIGJ5IHJldmVyc2Ugd29ya2VkLCBhbmQgSSd2ZSBsb25nIGFy Z3VlZCB0aGF0IGFsbG93aW5nIGFueXRoaW5nPGJyPg0KJmd0OyBvbiB0aGUgbmV0d29yayB3aXRo b3V0IHVzZWZ1bCByZXZlcnNlIEROUyBpcyBhIGJhZCB0aGluZywgYnV0IEkndmUgbG9zdCB0aGF0 KTxicj4NCiZndDsgPGJyPg0KJmd0OyBHb29nbGUsIEFrYW1haSwgRmFjZWJvb2ssIEFtYXpvbiwg QXp1cmUsIGV0Yy4gYWxsIHByb3ZpZGUgZm9yIChJb1QgZGV2aWNlKTxicj4NCiZndDsgdGVybWlu YXRpb24gYnkgRE5TIHdoZXJlIHRoZSByZXN1bHQgcmV0dXJuZWQgZGVwZW5kcyB1cG9uIHdobyBh c2tzLiZuYnNwOyBUaGlzIGlzPGJyPg0KJmd0OyBkb25lIGZvciBnZW9sb2NhdGlvbiBhbmQgbG9h ZCBiYWxhbmNpbmcgcmVhc29ucy4mbmJzcDsgVXNlZCB0byBiZSBpdCB3YXMgYWxsPGJyPg0KJmd0 OyBSUiBETlMgcXVlcmllcyB3aXRoIFRUTC0wIHJlc3VsdHMsIGJ1dCBwcm92aWRlcnMgcmVhbGl6 ZWQgdGhhdCB0aGlzIHNjcmV3ZWQ8YnI+DQomZ3Q7IHVwIHRoZSBjYWNoaW5nIHByb3BlcnRpZXMg b24gdGhlaXIgc2VydmVycywgYW5kIGl0IHdhcyBiZXR0ZXIgdG8gcG9pbnQgYTxicj4NCiZndDsg Z2l2ZW4gdXNlci9ob3N0IGNvbnNpc3RlbnRseSB0byBhbiBlbnRyeSBzZXJ2ZXIuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IElmIHRoZSBNVUQtY29udHJvbGxlciBjYW4gcXVlcnkgdGhlIHNhbWUgcmVj dXJzaXZlIGNhY2hpbmcgRE5TIHNlcnZlciB0aGF0IHRoZTxicj4NCiZndDsgSW9UIGRldmljZSB3 aWxsIGxpa2VseSBnZXQgdGhlIHNhbWUgYW5zd2VyIGZyb20gdGhlIGNhY2hlLiZuYnNwOyBTbyB3 ZSBoYXZlIGEgaGlnaDxicj4NCiZndDsgcHJvYmFiaWxpdHkgb2Ygd2lubmluZy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgRE5TLW8tSFRUUFMgYnlwYXNzZXMgYWxsIHRoYXQgbG9jYWwgY2FjaGluZy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCB0byB3cml0ZSBhICZx dW90O09wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zIG9mIEROUyBsb29rdXBzPGJyPg0KJmd0OyBp biBNVUQgZmlsZXMmcXVvdDsgZG9jdW1lbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tPGJyPg0K Jmd0OyBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3IlMkJJRVRGQHNh bmRlbG1hbi5jYSIgdGFyZ2V0PSJfYmxhbmsiPm1jciYjNDM7SUVURkBzYW5kZWxtYW4uY2E8L2E+ Jmd0OywgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzPGJyPg0KJmd0OyAtPSBJUHY2IElvVCBjb25z dWx0aW5nID0tPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8 YnI+DQomZ3Q7IE11ZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpNdWRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5NdWRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211ZCIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL211ZDwvYT48YnI+DQo8YnI+DQotLSA8YnI+DQpNdWQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk11ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk11ZEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L211ZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tdWQ8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 ZGl2IGRpcj0ibHRyIj48c3Bhbj4tLSA8L3NwYW4+PGJyPg0KPHNwYW4+TXVkIG1haWxpbmcgbGlz dDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86TXVkQGlldGYub3JnIj5NdWRAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXVkIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL211ZDwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_9BF2E606D26241F5905CB7ECCBBB42FFciscocom_-- From nobody Mon May 27 03:15: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 076AE1200CC for ; Mon, 27 May 2019 03:15:36 -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 OQD5JYZkzcnC for ; Mon, 27 May 2019 03:15:33 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6102612004B for ; Mon, 27 May 2019 03:15:33 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id q21so12775580iog.13 for ; Mon, 27 May 2019 03:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=id4AWkbRMTjQyZKoLU35eFuVK5BWqWYMvnA8XJHAIKE=; b=DrNIWmnDsiVDMYAdw4JPoAfw8UmuiHpWuMdMCOyJ6VTctuU4dEjbW4yX9XvHxujP0b GRYxq0vHOfkB/zi4t+Ezau34lQYtZxkyRzOEcYOWnTkylsOOcMu+K67rSU+fIgQ1xblg 2xJc8Y7ZMRSf5so165Ab+qponoG/8MR4w4sG0F9Eovj1pLm789Gr3XHAvWOLjrRbsDHZ jvKkbXana5173ffpENrs0f/2gpmNz4+4zvnbWY397TmQU48wDZcGB3YteDVYwor7q2rK 2hQViR3Wux0splASUSYzAuCJr1r5DU5gFCrq3s+4co8uYs//WqFRw6DE7GKrHSwz7NUf OcGA== 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=id4AWkbRMTjQyZKoLU35eFuVK5BWqWYMvnA8XJHAIKE=; b=Yp3RVJj3hA+HAjqEfhVyEX40ivi+ikxCMy58zTzLuQeksLmjlfynDJjJpHL3mKhfE8 EFf05hsh1TkWrGuHmsHLmaZI+ecPsNmk78QFYG2YPUZ9UltHKy5yTYBAGRuz/oLJxhrJ AxKWZKcXojokJYjly3BBDK8tazI/r8VgiIva2VSeZG3sKvsOiIzV3+HOZJD/1+oeS4op zv9MBIo2G1KUgEaUqYE2YWwHuCWxbEKXGIs3n80CckG/q7rv55qI5aE21moNHUY5VVDF ojxLcVQduw3Hqvl99BGVmyLzQ1UTNwI1VBLl8RBEFrCpbOTC+dejEUHpNwc9iPu0tzKi yKuQ== X-Gm-Message-State: APjAAAVCWZeai4C7H13VWvQvUj0kpv7bA5roQNGvBw6HFA9aNk5wt/G0 aC6UxcAGpKx29NFg6zGqoX7qmbIMpgyg74aIKpI= X-Google-Smtp-Source: APXvYqxYoLHcY+N7J689AAsnRKDaw+0+YwDnHBg2bkZ+whcbLMlvnACizVL9OyoRIdcy1nn2KMsPMHUwfAJdEhdue+8= X-Received: by 2002:a5e:cb47:: with SMTP id h7mr65361094iok.69.1558952132582; Mon, 27 May 2019 03:15:32 -0700 (PDT) MIME-Version: 1.0 References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> In-Reply-To: <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> From: tirumal reddy Date: Mon, 27 May 2019 15:45:21 +0530 Message-ID: To: "Eliot Lear (elear)" Cc: Michael Richardson , "mud@ietf.org" Content-Type: multipart/alternative; boundary="00000000000015a0810589dbd4e1" 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: Mon, 27 May 2019 10:15:36 -0000 --00000000000015a0810589dbd4e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 27 May 2019 at 15:34, Eliot Lear (elear) wrote: > Absolutely true. And that matters if there is a vast quantity of crap on > those IPs. Worth keeping in mind. But this isn=E2=80=99t do much a MUD p= roblem as > more of a General hygiene matter. You are likely to block IPs with garba= ge > on them regardless of whether MUD is in play. > No, a IP address can serve both benign and malicious domains, just because a malicious domain is hosted on the same IP address simply blocking the IP address is not a good technique, access to benign domains will also be blocked. Firewalls typically grey-list such IP addresses and inspect the traffic. -Tiru > > Eliot > > On May 27, 2019, at 11:56, tirumal reddy wrote: > > If multiple domains are hosted on the same IP address and the IoT device > uses DOH, the enforcement point will not know the domain the IoT device i= s > visiting. Further, MUD controller may not even know the DOH server used b= y > the IoT device. > > Google supports domain fronting for its DOH server (see > https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y). > > Cheers, > -Tiru > > On Mon, 27 May 2019 at 13:41, Eliot Lear (elear) wrote: > >> To add to what Michael said the requirement is for consistency between >> the client and the enforcement point. There are several ways to do that >> with regard to DNS names. One is to snoop DNS. Another is for the resolv= er >> to coordinate with the enforcement point. Arguably the latter is the bet= ter >> approach but requires more work. >> >> The one mechanism that will certainly not work is DOH when the end devic= e >> ignores to resolve are handed to it by DHCP. >> >> Eliot >> >> > On May 27, 2019, at 03:28, Michael Richardson >> wrote: >> > >> > >> > In a private email, it was written: >> >> Okay, I admit I never realized there was an assumption built into MUD >> that >> >> the MUD enforcement point would be able to spy on DNS queries. I gues= s >> I had >> >> assumed one could do reverse DNS, and if that meant some lazy >> blocking, so be >> >> it. >> > >> > I don't know if it's an assumption built-in to MUD. >> > >> > The assumption in MUD is that a rule can be written in MUD that >> addresses >> > end points by name, and that if the MUD controller does it's own forwa= rd >> > lookup, that it gets the same results as the IoT device. >> > (I wish lookup by reverse worked, and I've long argued that allowing >> anything >> > on the network without useful reverse DNS is a bad thing, but I've los= t >> that) >> > >> > Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT >> device) >> > termination by DNS where the result returned depends upon who asks. >> This is >> > done for geolocation and load balancing reasons. Used to be it was al= l >> > RR DNS queries with TTL-0 results, but providers realized that this >> screwed >> > up the caching properties on their servers, and it was better to point= a >> > given user/host consistently to an entry server. >> > >> > If the MUD-controller can query the same recursive caching DNS server >> that the >> > IoT device will likely get the same answer from the cache. So we have >> a high >> > probability of winning. >> > >> > DNS-o-HTTPS bypasses all that local caching. >> > >> > I believe that we need to write a "Operational Considerations of DNS >> lookups >> > in MUD files" document. >> > >> > -- >> > Michael Richardson , Sandelman Software Works >> > -=3D IPv6 IoT consulting =3D- >> > >> > >> > >> > -- >> > Mud mailing list >> > Mud@ietf.org >> > https://www.ietf.org/mailman/listinfo/mud >> >> -- >> Mud mailing list >> Mud@ietf.org >> https://www.ietf.org/mailman/listinfo/mud >> > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > > --00000000000015a0810589dbd4e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 27 May 2019 at 15:34, Eliot Lear = (elear) <elear@cisco.com> wrot= e:
Absolutely true.=C2=A0 And that matters if there is a vast quantity of crap= on those IPs.=C2=A0 Worth keeping in mind. But this isn=E2=80=99t do much = a MUD problem as more of a General hygiene matter.=C2=A0 You are likely to = block IPs with garbage on them regardless of whether MUD is in play.=C2=A0

No, a IP address c= an serve both benign and malicious domains, just because a malicious domain= is hosted on the same IP address simply blocking the IP address is not a g= ood technique, access to benign domains will also be blocked. Firewalls typ= ically grey-list such IP addresses and inspect the traffic.

<= /div>
-Tiru
=C2=A0

Eliot=

On May 27, 2019, at 11:56, tirumal reddy <kondtir@gmail.com> wrote:

If multiple domains are hosted on the same IP address and = the IoT device uses DOH, the enforcement point will=C2=A0not know the domai= n the IoT device is visiting.=C2=A0Further, MUD controller may not even kno= w the=C2=A0DOH server used by the IoT device.=C2=A0

Google supports domain fronting for=C2=A0its DOH server (s= ee https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y).=

Cheers,
-Tiru

On Mon, 27 May 2019 at 13:41, Eliot L= ear (elear) <elear@= cisco.com> wrote:
To add to what Michael said the requirement is for consistency between the = client and the enforcement point. There are several ways to do that with re= gard to DNS names. One is to snoop DNS. Another is for the resolver to coor= dinate with the enforcement point. Arguably the latter is the better approach but requires more work.

The one mechanism that will certainly not work is DOH when the end device i= gnores to resolve are handed to it by DHCP.

Eliot

> On May 27, 2019, at 03:28, Michael Richardson <mcr+ietf@sandelman.ca> wrot= e:
>
>
> In a private email, it was written:
>> Okay, I admit I never realized there was an assumption built into = MUD that
>> the MUD enforcement point would be able to spy on DNS queries. I g= uess I had
>> assumed one could do reverse DNS, and if that meant some lazy bloc= king, so be
>> it.
>
> I don't know if it's an assumption built-in to MUD.
>
> The assumption in MUD is that a rule can be written in MUD that addres= ses
> end points by name, and that if the MUD controller does it's own f= orward
> lookup, that it gets the same results as the IoT device.
> (I wish lookup by reverse worked, and I've long argued that allowi= ng anything
> on the network without useful reverse DNS is a bad thing, but I've= lost that)
>
> Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT dev= ice)
> termination by DNS where the result returned depends upon who asks.=C2= =A0 This is
> done for geolocation and load balancing reasons.=C2=A0 Used to be it w= as all
> RR DNS queries with TTL-0 results, but providers realized that this sc= rewed
> up the caching properties on their servers, and it was better to point= a
> given user/host consistently to an entry server.
>
> If the MUD-controller can query the same recursive caching DNS server = that the
> IoT device will likely get the same answer from the cache.=C2=A0 So we= have a high
> probability of winning.
>
> DNS-o-HTTPS bypasses all that local caching.
>
> I believe that we need to write a "Operational Considerations of = DNS lookups
> in MUD files" document.
>
> --
> 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

--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud
--00000000000015a0810589dbd4e1-- From nobody Mon May 27 04:50: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 091B1120133 for ; Mon, 27 May 2019 04:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=b9Ifb0D8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oToSiunx 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 RlKBbsomJhxT for ; Mon, 27 May 2019 04:50:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7BB1200B8 for ; Mon, 27 May 2019 04:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15461; q=dns/txt; s=iport; t=1558957810; x=1560167410; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UrxMqYUHShxLsmhuP8TZaxKga/6yHrGo05vTFplHg9M=; b=b9Ifb0D85+6x511wuX7eusDc4SzGSPw6bdQOswOQVWdEfPlh10gqCH0U ip3oKu1UM1HMSv8yv05CaPpyhLMUiM5zCX1vapenx7rMbhtnqZFA0OO8u VgoULI7PbX9oyu6KynMysrgV5iy0WbV6NXjid8oO1zpwWEgCzG7ALYQ3t M=; IronPort-PHdr: =?us-ascii?q?9a23=3Aebs66hSrNE2xCULsCgxmpzwOHNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiE+Ec1YfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAABuzutc/5xdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2lVIAQLKIQTg0cDhFKKJ4IyJYlBiRqEUIEuFIEQA1Q?= =?us-ascii?q?JAQEBDAEBGAEKCgIBAYFLgnUCF4I+IzQJDgEDAQEEAQECAQRtHAyFSgEBAQM?= =?us-ascii?q?BAQEQER0BASwLAQQLAgEIGCcDAgICHwYLFBECBA4FIoMAAYEdTQMODwECDAO?= =?us-ascii?q?cNwKBOIhfcYEvgnkBAQWBMgGBFII0DQuCDwMGgTQBi1IXgUA/gTgME4IeLj6?= =?us-ascii?q?CGkcBAQKBIwkBEgEJQ4JdMoImiUOESYRjIJULPQkCgg2FNX+IfYNkG5ZJk3C?= =?us-ascii?q?BWo0cAgQCBAUCDgEBBYFPODYwcXAVOyoBgkGCDwwXg02FFIU/coEpinOCQwE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.60,519,1549929600"; d="scan'208,217";a="563240033" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2019 11:50:07 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x4RBo4gA004728 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2019 11:50:06 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 06:50:05 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 07:50:04 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 27 May 2019 07:50:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UrxMqYUHShxLsmhuP8TZaxKga/6yHrGo05vTFplHg9M=; b=oToSiunx0eVvUa5/WSHTJ+lKygcKCRB10mx3SypffqKL7xkm7Af+lL6rWNB5RvU1Z+Q0ncRBvPTLvwABKFIexEVjcPhXWCyc3GFxjZN2MwsHgIGbX4dCMjRPaep4cgfitvsPc84ioUfHvaaqR10pvhjHlnT3J7wWyub44kdngiE= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3479.namprd11.prod.outlook.com (20.177.187.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.23; Mon, 27 May 2019 11:50:02 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56%7]) with mapi id 15.20.1922.021; Mon, 27 May 2019 11:50:02 +0000 From: "Eliot Lear (elear)" To: tirumal reddy CC: Michael Richardson , "mud@ietf.org" Thread-Topic: [Mud] Unique credentials for devices in a home network Thread-Index: AQHVFCuKU8uy2WzIwUG3dhABmH6VcKZ+gQ1egAA7JgCAAAKUr4AAAxCAgAAadSI= Date: Mon, 27 May 2019 11:50:02 +0000 Message-ID: <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@cisco.com> References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:152b:ecc6:f97f:7d49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d97bca3-7887-4207-6617-08d6e2997449 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3479; x-ms-traffictypediagnostic: BYAPR11MB3479: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(376002)(366004)(396003)(199004)(189003)(53936002)(36756003)(6436002)(54906003)(316002)(606006)(5660300002)(6486002)(478600001)(966005)(14454004)(86362001)(7736002)(1411001)(256004)(6306002)(6512007)(54896002)(236005)(14444005)(2906002)(73956011)(66556008)(66476007)(6116002)(82746002)(33656002)(446003)(66946007)(6506007)(25786009)(53546011)(102836004)(46003)(8676002)(81166006)(76116006)(486006)(91956017)(11346002)(76176011)(476003)(68736007)(64756008)(229853002)(71190400001)(83716004)(6246003)(71200400001)(517774005)(186003)(99286004)(8936002)(4326008)(6916009)(2616005)(81156014)(5070765005)(66446008)(222643001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3479; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AFvChvEzzfyjV3nFNuvp+r7hslWrcQdBZpTPF8/kUcdcKxclPhBdWGR3KGnLAJUh+KtsIAZ+j6nY/kF0TcmH/pnsSeZQxtoeRTd6S1kkfQ8ZkPXJLDYhEeLBtpRqNTxlnsIwEz5cn7hbM4k35rt+c2FRC9viwUeUjAqPhaqWD3/WfWv5e9R4FnP87ujFnVjkyhhz7adHXg4oYAtUq277lHTGOvQzurIuCnRUad/qxMEBqbaGO+cPhQFy6FdutWJgqm++oVUv25FH502n/rvvC2W3OCPnxEc0tYtJiYs3tXAkhyl0gPrHHp1T04HgmTzcghCDS2M7AB9IF4BeZKHCwuxUbxVQNA69Yq43ikvvdzYLxQJIvn7SaEQcpja8FDe/XMZd3wlFWmronbFbfKdtTGfTVb06p2cmvDTIB+/UEP8= Content-Type: multipart/alternative; boundary="_000_8BC6C67EB6B54524B40D5D0E48476CBFciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9d97bca3-7887-4207-6617-08d6e2997449 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2019 11:50:02.7115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: elear@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3479 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com 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: Mon, 27 May 2019 11:50:15 -0000 --_000_8BC6C67EB6B54524B40D5D0E48476CBFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbiBkbyB0aGUgc2FtZSBoZXJlLiBXaGF0IGhhcyBvbmUgYWR2YW50YWdlOiB5b3Uga25v dyB0aGUgcHVycG9zZSBvZiB0aGUgY29tbXVuaWNhdGlvbi4NCg0KRWxpb3QNCg0KT24gTWF5IDI3 LCAyMDE5LCBhdCAxMjoxNiwgdGlydW1hbCByZWRkeSA8a29uZHRpckBnbWFpbC5jb208bWFpbHRv OmtvbmR0aXJAZ21haWwuY29tPj4gd3JvdGU6DQoNCk9uIE1vbiwgMjcgTWF5IDIwMTkgYXQgMTU6 MzQsIEVsaW90IExlYXIgKGVsZWFyKSA8ZWxlYXJAY2lzY28uY29tPG1haWx0bzplbGVhckBjaXNj by5jb20+PiB3cm90ZToNCkFic29sdXRlbHkgdHJ1ZS4gIEFuZCB0aGF0IG1hdHRlcnMgaWYgdGhl cmUgaXMgYSB2YXN0IHF1YW50aXR5IG9mIGNyYXAgb24gdGhvc2UgSVBzLiAgV29ydGgga2VlcGlu ZyBpbiBtaW5kLiBCdXQgdGhpcyBpc27igJl0IGRvIG11Y2ggYSBNVUQgcHJvYmxlbSBhcyBtb3Jl IG9mIGEgR2VuZXJhbCBoeWdpZW5lIG1hdHRlci4gIFlvdSBhcmUgbGlrZWx5IHRvIGJsb2NrIElQ cyB3aXRoIGdhcmJhZ2Ugb24gdGhlbSByZWdhcmRsZXNzIG9mIHdoZXRoZXIgTVVEIGlzIGluIHBs YXkuDQoNCk5vLCBhIElQIGFkZHJlc3MgY2FuIHNlcnZlIGJvdGggYmVuaWduIGFuZCBtYWxpY2lv dXMgZG9tYWlucywganVzdCBiZWNhdXNlIGEgbWFsaWNpb3VzIGRvbWFpbiBpcyBob3N0ZWQgb24g dGhlIHNhbWUgSVAgYWRkcmVzcyBzaW1wbHkgYmxvY2tpbmcgdGhlIElQIGFkZHJlc3MgaXMgbm90 IGEgZ29vZCB0ZWNobmlxdWUsIGFjY2VzcyB0byBiZW5pZ24gZG9tYWlucyB3aWxsIGFsc28gYmUg YmxvY2tlZC4gRmlyZXdhbGxzIHR5cGljYWxseSBncmV5LWxpc3Qgc3VjaCBJUCBhZGRyZXNzZXMg YW5kIGluc3BlY3QgdGhlIHRyYWZmaWMuDQoNCi1UaXJ1DQoNCg0KRWxpb3QNCg0KT24gTWF5IDI3 LCAyMDE5LCBhdCAxMTo1NiwgdGlydW1hbCByZWRkeSA8a29uZHRpckBnbWFpbC5jb208bWFpbHRv OmtvbmR0aXJAZ21haWwuY29tPj4gd3JvdGU6DQoNCklmIG11bHRpcGxlIGRvbWFpbnMgYXJlIGhv c3RlZCBvbiB0aGUgc2FtZSBJUCBhZGRyZXNzIGFuZCB0aGUgSW9UIGRldmljZSB1c2VzIERPSCwg dGhlIGVuZm9yY2VtZW50IHBvaW50IHdpbGwgbm90IGtub3cgdGhlIGRvbWFpbiB0aGUgSW9UIGRl dmljZSBpcyB2aXNpdGluZy4gRnVydGhlciwgTVVEIGNvbnRyb2xsZXIgbWF5IG5vdCBldmVuIGtu b3cgdGhlIERPSCBzZXJ2ZXIgdXNlZCBieSB0aGUgSW9UIGRldmljZS4NCg0KR29vZ2xlIHN1cHBv cnRzIGRvbWFpbiBmcm9udGluZyBmb3IgaXRzIERPSCBzZXJ2ZXIgKHNlZSBodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RvaC85NU10d1RTVXhjU1ZDVUN4amFCaHB4MG05OFkp Lg0KDQpDaGVlcnMsDQotVGlydQ0KDQpPbiBNb24sIDI3IE1heSAyMDE5IGF0IDEzOjQxLCBFbGlv dCBMZWFyIChlbGVhcikgPGVsZWFyQGNpc2NvLmNvbTxtYWlsdG86ZWxlYXJAY2lzY28uY29tPj4g d3JvdGU6DQpUbyBhZGQgdG8gd2hhdCBNaWNoYWVsIHNhaWQgdGhlIHJlcXVpcmVtZW50IGlzIGZv ciBjb25zaXN0ZW5jeSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBlbmZvcmNlbWVudCBwb2lu dC4gVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBkbyB0aGF0IHdpdGggcmVnYXJkIHRvIEROUyBu YW1lcy4gT25lIGlzIHRvIHNub29wIEROUy4gQW5vdGhlciBpcyBmb3IgdGhlIHJlc29sdmVyIHRv IGNvb3JkaW5hdGUgd2l0aCB0aGUgZW5mb3JjZW1lbnQgcG9pbnQuIEFyZ3VhYmx5IHRoZSBsYXR0 ZXIgaXMgdGhlIGJldHRlciBhcHByb2FjaCBidXQgcmVxdWlyZXMgbW9yZSB3b3JrLg0KDQpUaGUg b25lIG1lY2hhbmlzbSB0aGF0IHdpbGwgY2VydGFpbmx5IG5vdCB3b3JrIGlzIERPSCB3aGVuIHRo ZSBlbmQgZGV2aWNlIGlnbm9yZXMgdG8gcmVzb2x2ZSBhcmUgaGFuZGVkIHRvIGl0IGJ5IERIQ1Au DQoNCkVsaW90DQoNCj4gT24gTWF5IDI3LCAyMDE5LCBhdCAwMzoyOCwgTWljaGFlbCBSaWNoYXJk c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jciUyQmlldGZAc2FuZGVsbWFuLmNh Pj4gd3JvdGU6DQo+DQo+DQo+IEluIGEgcHJpdmF0ZSBlbWFpbCwgaXQgd2FzIHdyaXR0ZW46DQo+ PiBPa2F5LCBJIGFkbWl0IEkgbmV2ZXIgcmVhbGl6ZWQgdGhlcmUgd2FzIGFuIGFzc3VtcHRpb24g YnVpbHQgaW50byBNVUQgdGhhdA0KPj4gdGhlIE1VRCBlbmZvcmNlbWVudCBwb2ludCB3b3VsZCBi ZSBhYmxlIHRvIHNweSBvbiBETlMgcXVlcmllcy4gSSBndWVzcyBJIGhhZA0KPj4gYXNzdW1lZCBv bmUgY291bGQgZG8gcmV2ZXJzZSBETlMsIGFuZCBpZiB0aGF0IG1lYW50IHNvbWUgbGF6eSBibG9j a2luZywgc28gYmUNCj4+IGl0Lg0KPg0KPiBJIGRvbid0IGtub3cgaWYgaXQncyBhbiBhc3N1bXB0 aW9uIGJ1aWx0LWluIHRvIE1VRC4NCj4NCj4gVGhlIGFzc3VtcHRpb24gaW4gTVVEIGlzIHRoYXQg YSBydWxlIGNhbiBiZSB3cml0dGVuIGluIE1VRCB0aGF0IGFkZHJlc3Nlcw0KPiBlbmQgcG9pbnRz IGJ5IG5hbWUsIGFuZCB0aGF0IGlmIHRoZSBNVUQgY29udHJvbGxlciBkb2VzIGl0J3Mgb3duIGZv cndhcmQNCj4gbG9va3VwLCB0aGF0IGl0IGdldHMgdGhlIHNhbWUgcmVzdWx0cyBhcyB0aGUgSW9U IGRldmljZS4NCj4gKEkgd2lzaCBsb29rdXAgYnkgcmV2ZXJzZSB3b3JrZWQsIGFuZCBJJ3ZlIGxv bmcgYXJndWVkIHRoYXQgYWxsb3dpbmcgYW55dGhpbmcNCj4gb24gdGhlIG5ldHdvcmsgd2l0aG91 dCB1c2VmdWwgcmV2ZXJzZSBETlMgaXMgYSBiYWQgdGhpbmcsIGJ1dCBJJ3ZlIGxvc3QgdGhhdCkN Cj4NCj4gR29vZ2xlLCBBa2FtYWksIEZhY2Vib29rLCBBbWF6b24sIEF6dXJlLCBldGMuIGFsbCBw cm92aWRlIGZvciAoSW9UIGRldmljZSkNCj4gdGVybWluYXRpb24gYnkgRE5TIHdoZXJlIHRoZSBy ZXN1bHQgcmV0dXJuZWQgZGVwZW5kcyB1cG9uIHdobyBhc2tzLiAgVGhpcyBpcw0KPiBkb25lIGZv ciBnZW9sb2NhdGlvbiBhbmQgbG9hZCBiYWxhbmNpbmcgcmVhc29ucy4gIFVzZWQgdG8gYmUgaXQg d2FzIGFsbA0KPiBSUiBETlMgcXVlcmllcyB3aXRoIFRUTC0wIHJlc3VsdHMsIGJ1dCBwcm92aWRl cnMgcmVhbGl6ZWQgdGhhdCB0aGlzIHNjcmV3ZWQNCj4gdXAgdGhlIGNhY2hpbmcgcHJvcGVydGll cyBvbiB0aGVpciBzZXJ2ZXJzLCBhbmQgaXQgd2FzIGJldHRlciB0byBwb2ludCBhDQo+IGdpdmVu IHVzZXIvaG9zdCBjb25zaXN0ZW50bHkgdG8gYW4gZW50cnkgc2VydmVyLg0KPg0KPiBJZiB0aGUg TVVELWNvbnRyb2xsZXIgY2FuIHF1ZXJ5IHRoZSBzYW1lIHJlY3Vyc2l2ZSBjYWNoaW5nIEROUyBz ZXJ2ZXIgdGhhdCB0aGUNCj4gSW9UIGRldmljZSB3aWxsIGxpa2VseSBnZXQgdGhlIHNhbWUgYW5z d2VyIGZyb20gdGhlIGNhY2hlLiAgU28gd2UgaGF2ZSBhIGhpZ2gNCj4gcHJvYmFiaWxpdHkgb2Yg d2lubmluZy4NCj4NCj4gRE5TLW8tSFRUUFMgYnlwYXNzZXMgYWxsIHRoYXQgbG9jYWwgY2FjaGlu Zy4NCj4NCj4gSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCB0byB3cml0ZSBhICJPcGVyYXRpb25hbCBD b25zaWRlcmF0aW9ucyBvZiBETlMgbG9va3Vwcw0KPiBpbiBNVUQgZmlsZXMiIGRvY3VtZW50Lg0K Pg0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYTxtYWls dG86bWNyJTJCSUVURkBzYW5kZWxtYW4uY2E+PiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQo+ IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4NCj4NCj4NCj4gLS0NCj4gTXVkIG1haWxpbmcg bGlzdA0KPiBNdWRAaWV0Zi5vcmc8bWFpbHRvOk11ZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQNCg0KLS0NCk11ZCBtYWlsaW5nIGxpc3QNCk11 ZEBpZXRmLm9yZzxtYWlsdG86TXVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tdWQNCi0tDQpNdWQgbWFpbGluZyBsaXN0DQpNdWRAaWV0Zi5vcmc8bWFp bHRvOk11ZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXVkDQotLQ0KTXVkIG1haWxpbmcgbGlzdA0KTXVkQGlldGYub3JnPG1haWx0bzpNdWRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211ZA0K --_000_8BC6C67EB6B54524B40D5D0E48476CBFciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpZ b3UgY2FuIGRvIHRoZSBzYW1lIGhlcmUuIFdoYXQgaGFzIG9uZSBhZHZhbnRhZ2U6IHlvdSBrbm93 IHRoZSBwdXJwb3NlIG9mIHRoZSBjb21tdW5pY2F0aW9uLjxicj4NCjxicj4NCjxkaXYgaWQ9IkFw cGxlTWFpbFNpZ25hdHVyZSIgZGlyPSJsdHIiPkVsaW90PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48 YnI+DQpPbiBNYXkgMjcsIDIwMTksIGF0IDEyOjE2LCB0aXJ1bWFsIHJlZGR5ICZsdDs8YSBocmVm PSJtYWlsdG86a29uZHRpckBnbWFpbC5jb20iPmtvbmR0aXJAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj5PbiBNb24sIDI3IE1heSAy MDE5IGF0IDE1OjM0LCBFbGlvdCBMZWFyIChlbGVhcikgJmx0OzxhIGhyZWY9Im1haWx0bzplbGVh ckBjaXNjby5jb20iPmVsZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCBy Z2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPkFic29s dXRlbHkgdHJ1ZS4mbmJzcDsgQW5kIHRoYXQgbWF0dGVycyBpZiB0aGVyZSBpcyBhIHZhc3QgcXVh bnRpdHkgb2YgY3JhcCBvbiB0aG9zZSBJUHMuJm5ic3A7IFdvcnRoIGtlZXBpbmcgaW4gbWluZC4g QnV0IHRoaXMgaXNu4oCZdCBkbyBtdWNoIGEgTVVEIHByb2JsZW0gYXMgbW9yZSBvZiBhIEdlbmVy YWwgaHlnaWVuZSBtYXR0ZXIuJm5ic3A7IFlvdSBhcmUgbGlrZWx5IHRvIGJsb2NrIElQcyB3aXRo IGdhcmJhZ2Ugb24gdGhlbSByZWdhcmRsZXNzDQogb2Ygd2hldGhlciBNVUQgaXMgaW4gcGxheS4m bmJzcDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vLCBh IElQIGFkZHJlc3MgY2FuIHNlcnZlIGJvdGggYmVuaWduIGFuZCBtYWxpY2lvdXMgZG9tYWlucywg anVzdCBiZWNhdXNlIGEgbWFsaWNpb3VzIGRvbWFpbiBpcyBob3N0ZWQgb24gdGhlIHNhbWUgSVAg YWRkcmVzcyBzaW1wbHkgYmxvY2tpbmcgdGhlIElQIGFkZHJlc3MgaXMgbm90IGEgZ29vZCB0ZWNo bmlxdWUsIGFjY2VzcyB0byBiZW5pZ24gZG9tYWlucyB3aWxsIGFsc28gYmUgYmxvY2tlZC4gRmly ZXdhbGxzIHR5cGljYWxseSBncmV5LWxpc3QNCiBzdWNoIElQIGFkZHJlc3NlcyBhbmQgaW5zcGVj dCB0aGUgdHJhZmZpYy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1UaXJ1PGJyPg0K PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCBy Z2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRp dj48YnI+DQo8ZGl2IGlkPSJnbWFpbC1tXzMxMzYyODk1NjgwMDUzNzM3NjVBcHBsZU1haWxTaWdu YXR1cmUiIGRpcj0ibHRyIj5FbGlvdDwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KT24gTWF5 IDI3LCAyMDE5LCBhdCAxMTo1NiwgdGlydW1hbCByZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtv bmR0aXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a29uZHRpckBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPklmIG11bHRpcGxl IGRvbWFpbnMgYXJlIGhvc3RlZCBvbiB0aGUgc2FtZSBJUCBhZGRyZXNzIGFuZCB0aGUgSW9UIGRl dmljZSB1c2VzIERPSCwgdGhlIGVuZm9yY2VtZW50IHBvaW50IHdpbGwmbmJzcDtub3Qga25vdyB0 aGUgZG9tYWluIHRoZSBJb1QgZGV2aWNlIGlzIHZpc2l0aW5nLiZuYnNwO0Z1cnRoZXIsIE1VRCBj b250cm9sbGVyIG1heSBub3QgZXZlbiBrbm93IHRoZSZuYnNwO0RPSCBzZXJ2ZXIgdXNlZCBieSB0 aGUgSW9UIGRldmljZS4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0K PGRpdiBkaXI9Imx0ciI+R29vZ2xlIHN1cHBvcnRzIGRvbWFpbiBmcm9udGluZyBmb3ImbmJzcDtp dHMgRE9IIHNlcnZlciAoc2VlIDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvZG9oLzk1TXR3VFNVeGNTVkNVQ3hqYUJocHgwbTk4WSIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kb2gvOTVNdHdUU1V4Y1NW Q1VDeGphQmhweDBtOThZPC9hPikuPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8 L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj4tVGlydTwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJn bWFpbF9hdHRyIj5PbiBNb24sIDI3IE1heSAyMDE5IGF0IDEzOjQxLCBFbGlvdCBMZWFyIChlbGVh cikgJmx0OzxhIGhyZWY9Im1haWx0bzplbGVhckBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5l bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXIt bGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NClRvIGFk ZCB0byB3aGF0IE1pY2hhZWwgc2FpZCB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGNvbnNpc3RlbmN5 IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGVuZm9yY2VtZW50IHBvaW50LiBUaGVyZSBhcmUg c2V2ZXJhbCB3YXlzIHRvIGRvIHRoYXQgd2l0aCByZWdhcmQgdG8gRE5TIG5hbWVzLiBPbmUgaXMg dG8gc25vb3AgRE5TLiBBbm90aGVyIGlzIGZvciB0aGUgcmVzb2x2ZXIgdG8gY29vcmRpbmF0ZSB3 aXRoIHRoZSBlbmZvcmNlbWVudCBwb2ludC4NCiBBcmd1YWJseSB0aGUgbGF0dGVyIGlzIHRoZSBi ZXR0ZXIgYXBwcm9hY2ggYnV0IHJlcXVpcmVzIG1vcmUgd29yay4gPGJyPg0KPGJyPg0KVGhlIG9u ZSBtZWNoYW5pc20gdGhhdCB3aWxsIGNlcnRhaW5seSBub3Qgd29yayBpcyBET0ggd2hlbiB0aGUg ZW5kIGRldmljZSBpZ25vcmVzIHRvIHJlc29sdmUgYXJlIGhhbmRlZCB0byBpdCBieSBESENQLjxi cj4NCjxicj4NCkVsaW90PGJyPg0KPGJyPg0KJmd0OyBPbiBNYXkgMjcsIDIwMTksIGF0IDAzOjI4 LCBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3IlMkJpZXRmQHNhbmRl bG1hbi5jYSIgdGFyZ2V0PSJfYmxhbmsiPm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiBhIHByaXZhdGUgZW1h aWwsIGl0IHdhcyB3cml0dGVuOjxicj4NCiZndDsmZ3Q7IE9rYXksIEkgYWRtaXQgSSBuZXZlciBy ZWFsaXplZCB0aGVyZSB3YXMgYW4gYXNzdW1wdGlvbiBidWlsdCBpbnRvIE1VRCB0aGF0PGJyPg0K Jmd0OyZndDsgdGhlIE1VRCBlbmZvcmNlbWVudCBwb2ludCB3b3VsZCBiZSBhYmxlIHRvIHNweSBv biBETlMgcXVlcmllcy4gSSBndWVzcyBJIGhhZDxicj4NCiZndDsmZ3Q7IGFzc3VtZWQgb25lIGNv dWxkIGRvIHJldmVyc2UgRE5TLCBhbmQgaWYgdGhhdCBtZWFudCBzb21lIGxhenkgYmxvY2tpbmcs IHNvIGJlPGJyPg0KJmd0OyZndDsgaXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG9uJ3Qga25v dyBpZiBpdCdzIGFuIGFzc3VtcHRpb24gYnVpbHQtaW4gdG8gTVVELjxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGUgYXNzdW1wdGlvbiBpbiBNVUQgaXMgdGhhdCBhIHJ1bGUgY2FuIGJlIHdyaXR0ZW4g aW4gTVVEIHRoYXQgYWRkcmVzc2VzPGJyPg0KJmd0OyBlbmQgcG9pbnRzIGJ5IG5hbWUsIGFuZCB0 aGF0IGlmIHRoZSBNVUQgY29udHJvbGxlciBkb2VzIGl0J3Mgb3duIGZvcndhcmQ8YnI+DQomZ3Q7 IGxvb2t1cCwgdGhhdCBpdCBnZXRzIHRoZSBzYW1lIHJlc3VsdHMgYXMgdGhlIElvVCBkZXZpY2Uu PGJyPg0KJmd0OyAoSSB3aXNoIGxvb2t1cCBieSByZXZlcnNlIHdvcmtlZCwgYW5kIEkndmUgbG9u ZyBhcmd1ZWQgdGhhdCBhbGxvd2luZyBhbnl0aGluZzxicj4NCiZndDsgb24gdGhlIG5ldHdvcmsg d2l0aG91dCB1c2VmdWwgcmV2ZXJzZSBETlMgaXMgYSBiYWQgdGhpbmcsIGJ1dCBJJ3ZlIGxvc3Qg dGhhdCk8YnI+DQomZ3Q7IDxicj4NCiZndDsgR29vZ2xlLCBBa2FtYWksIEZhY2Vib29rLCBBbWF6 b24sIEF6dXJlLCBldGMuIGFsbCBwcm92aWRlIGZvciAoSW9UIGRldmljZSk8YnI+DQomZ3Q7IHRl cm1pbmF0aW9uIGJ5IEROUyB3aGVyZSB0aGUgcmVzdWx0IHJldHVybmVkIGRlcGVuZHMgdXBvbiB3 aG8gYXNrcy4mbmJzcDsgVGhpcyBpczxicj4NCiZndDsgZG9uZSBmb3IgZ2VvbG9jYXRpb24gYW5k IGxvYWQgYmFsYW5jaW5nIHJlYXNvbnMuJm5ic3A7IFVzZWQgdG8gYmUgaXQgd2FzIGFsbDxicj4N CiZndDsgUlIgRE5TIHF1ZXJpZXMgd2l0aCBUVEwtMCByZXN1bHRzLCBidXQgcHJvdmlkZXJzIHJl YWxpemVkIHRoYXQgdGhpcyBzY3Jld2VkPGJyPg0KJmd0OyB1cCB0aGUgY2FjaGluZyBwcm9wZXJ0 aWVzIG9uIHRoZWlyIHNlcnZlcnMsIGFuZCBpdCB3YXMgYmV0dGVyIHRvIHBvaW50IGE8YnI+DQom Z3Q7IGdpdmVuIHVzZXIvaG9zdCBjb25zaXN0ZW50bHkgdG8gYW4gZW50cnkgc2VydmVyLjxicj4N CiZndDsgPGJyPg0KJmd0OyBJZiB0aGUgTVVELWNvbnRyb2xsZXIgY2FuIHF1ZXJ5IHRoZSBzYW1l IHJlY3Vyc2l2ZSBjYWNoaW5nIEROUyBzZXJ2ZXIgdGhhdCB0aGU8YnI+DQomZ3Q7IElvVCBkZXZp Y2Ugd2lsbCBsaWtlbHkgZ2V0IHRoZSBzYW1lIGFuc3dlciBmcm9tIHRoZSBjYWNoZS4mbmJzcDsg U28gd2UgaGF2ZSBhIGhpZ2g8YnI+DQomZ3Q7IHByb2JhYmlsaXR5IG9mIHdpbm5pbmcuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEROUy1vLUhUVFBTIGJ5cGFzc2VzIGFsbCB0aGF0IGxvY2FsIGNhY2hp bmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgdG8gd3JpdGUg YSAmcXVvdDtPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyBvZiBETlMgbG9va3Vwczxicj4NCiZn dDsgaW4gTVVEIGZpbGVzJnF1b3Q7IGRvY3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAtLTxi cj4NCiZndDsgTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJTJCSUVU RkBzYW5kZWxtYW4uY2EiIHRhcmdldD0iX2JsYW5rIj5tY3ImIzQzO0lFVEZAc2FuZGVsbWFuLmNh PC9hPiZndDssIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrczxicj4NCiZndDsgLT0gSVB2NiBJb1Qg Y29uc3VsdGluZyA9LTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg LS0gPGJyPg0KJmd0OyBNdWQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86 TXVkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TXVkQGlldGYub3JnPC9hPjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQiIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tdWQ8L2E+PGJyPg0KPGJyPg0KLS0gPGJyPg0KTXVkIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpNdWRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5NdWRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tdWQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVkPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4+LS0gPC9zcGFuPjxicj4NCjxzcGFuPk11ZCBtYWlsaW5n IGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOk11ZEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPk11ZEBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211ZDwvYT48L3NwYW4+PGJy Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bhbj4tLSA8L3NwYW4+PGJyPg0KPHNwYW4+TXVkIG1h aWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86TXVkQGlldGYub3Jn Ij5NdWRAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVkIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL211ZDwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_8BC6C67EB6B54524B40D5D0E48476CBFciscocom_-- From nobody Mon May 27 05:53:45 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 105D4120155 for ; Mon, 27 May 2019 05:53:44 -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 iY_NcEVHMVER for ; Mon, 27 May 2019 05:53:41 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 2732A12010F for ; Mon, 27 May 2019 05:53:41 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id m3so26694520itl.1 for ; Mon, 27 May 2019 05:53:41 -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=f3Qv1JIge4rHjhONKC3KIxcsp33MOA6Z2zrNSUtTHFs=; b=ALhmD4l4GZapZiIO8gC3AK68W+Q7q5g3SI3WdFVVP4oTvsAyidnt9av7+xBRdVfLrq z2bWjGX12IpvLBuT/2GcH64CDVVN5rSuGL9aZ1GBZdJNt+stzwBAbizW0yZhdrQhUC+I uc0w5DyKSM7W99jcj8+q8DNHuSVFPiYoP7NRbxkeSjreyzQmwWY5d2oLiJXxgb9OajrA 6Rhful3b9zqoBt6NbvvPUEcyf1o+5p4jTyBfblucg9RBDciJJRDlTH0bgSn/8/2vOl6r nrqAXcjW8YvIlq7AVil5VlpOkziyJb6rOyonlQ8n2LqTe3yiXvX8ZieknD4Hy/nBKOCI MD3Q== 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=f3Qv1JIge4rHjhONKC3KIxcsp33MOA6Z2zrNSUtTHFs=; b=RUDERPRjHuHqLqIXGlAVdFH9yg5jiV2kXHpZpJAaG4Kk60BW5XPkLfquqXWUxLQdSt AdCfVq23fR/Dv07byoCO9Dg16pUSr/qzPcNaCDg87egYY9l9J6A4gVG/3cwT5BprZUnT ILzJ7h/mix8lCqMIzRp/4E698lV+UQ3bKNaoqV8vp+Lfd7v/CAGICXWihZW4rtiuZX4d ydAFDeYpMAlR3NwwTP+yYC80GerDPe0+XVL4aj3SlvkpLKWieKZjjdheIDHrOA8tnH2D 758JlMyK25gV5HfrekHU0HuSd7fIpJLHvQmaUoS7tJH5qirphPzXZ/idu5hG9eFJPw3u ALlQ== X-Gm-Message-State: APjAAAXbh3KbHKKA7nHwNWWINpuvOZnYO3DMEPY0q/k2wtj6DjGdGwCg 7sN2Gab/DWhmJWyZsH9oE0Fl5YXt07EYa5riSsQ= X-Google-Smtp-Source: APXvYqztq+IDfspw+JCPDXzcwnFe+zBN/U5oS0rslT2/p10QGMmpBlGeZ4+YSHlo6c1OvuBQfb2qVKx/i4m+KItJRgo= X-Received: by 2002:a02:9a03:: with SMTP id b3mr10125429jal.35.1558961620399; Mon, 27 May 2019 05:53:40 -0700 (PDT) MIME-Version: 1.0 References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@cisco.com> In-Reply-To: <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@cisco.com> From: tirumal reddy Date: Mon, 27 May 2019 18:23:28 +0530 Message-ID: To: "Eliot Lear (elear)" Cc: Michael Richardson , "mud@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009a3d330589de09db" 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: Mon, 27 May 2019 12:53:44 -0000 --0000000000009a3d330589de09db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 27 May 2019 at 17:20, Eliot Lear (elear) wrote: > You can do the same here. What has one advantage: you know the purpose of > the communication. > Yes, encrypted traffic inspection is possible in Enterprise networks (acting as TLS proxy) but not in home networks. If the enforcement point in home network cannot snoop/inspect DNS traffic, looking into the traffic to the IP address will not not reveal the domain name with TLS 1.3 and ESNI. Cheers, -Tiru > > Eliot > > On May 27, 2019, at 12:16, tirumal reddy wrote: > > On Mon, 27 May 2019 at 15:34, Eliot Lear (elear) wrote: > >> Absolutely true. And that matters if there is a vast quantity of crap o= n >> those IPs. Worth keeping in mind. But this isn=E2=80=99t do much a MUD = problem as >> more of a General hygiene matter. You are likely to block IPs with garb= age >> on them regardless of whether MUD is in play. >> > > No, a IP address can serve both benign and malicious domains, just becaus= e > a malicious domain is hosted on the same IP address simply blocking the I= P > address is not a good technique, access to benign domains will also be > blocked. Firewalls typically grey-list such IP addresses and inspect the > traffic. > > -Tiru > > >> >> Eliot >> >> On May 27, 2019, at 11:56, tirumal reddy wrote: >> >> If multiple domains are hosted on the same IP address and the IoT device >> uses DOH, the enforcement point will not know the domain the IoT device = is >> visiting. Further, MUD controller may not even know the DOH server used = by >> the IoT device. >> >> Google supports domain fronting for its DOH server (see >> https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y). >> >> Cheers, >> -Tiru >> >> On Mon, 27 May 2019 at 13:41, Eliot Lear (elear) wrote= : >> >>> To add to what Michael said the requirement is for consistency between >>> the client and the enforcement point. There are several ways to do that >>> with regard to DNS names. One is to snoop DNS. Another is for the resol= ver >>> to coordinate with the enforcement point. Arguably the latter is the be= tter >>> approach but requires more work. >>> >>> The one mechanism that will certainly not work is DOH when the end >>> device ignores to resolve are handed to it by DHCP. >>> >>> Eliot >>> >>> > On May 27, 2019, at 03:28, Michael Richardson >>> wrote: >>> > >>> > >>> > In a private email, it was written: >>> >> Okay, I admit I never realized there was an assumption built into MU= D >>> that >>> >> the MUD enforcement point would be able to spy on DNS queries. I >>> guess I had >>> >> assumed one could do reverse DNS, and if that meant some lazy >>> blocking, so be >>> >> it. >>> > >>> > I don't know if it's an assumption built-in to MUD. >>> > >>> > The assumption in MUD is that a rule can be written in MUD that >>> addresses >>> > end points by name, and that if the MUD controller does it's own >>> forward >>> > lookup, that it gets the same results as the IoT device. >>> > (I wish lookup by reverse worked, and I've long argued that allowing >>> anything >>> > on the network without useful reverse DNS is a bad thing, but I've >>> lost that) >>> > >>> > Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT >>> device) >>> > termination by DNS where the result returned depends upon who asks. >>> This is >>> > done for geolocation and load balancing reasons. Used to be it was a= ll >>> > RR DNS queries with TTL-0 results, but providers realized that this >>> screwed >>> > up the caching properties on their servers, and it was better to poin= t >>> a >>> > given user/host consistently to an entry server. >>> > >>> > If the MUD-controller can query the same recursive caching DNS server >>> that the >>> > IoT device will likely get the same answer from the cache. So we hav= e >>> a high >>> > probability of winning. >>> > >>> > DNS-o-HTTPS bypasses all that local caching. >>> > >>> > I believe that we need to write a "Operational Considerations of DNS >>> lookups >>> > in MUD files" document. >>> > >>> > -- >>> > Michael Richardson , Sandelman Software Works >>> > -=3D IPv6 IoT consulting =3D- >>> > >>> > >>> > >>> > -- >>> > Mud mailing list >>> > Mud@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mud >>> >>> -- >>> Mud mailing list >>> Mud@ietf.org >>> https://www.ietf.org/mailman/listinfo/mud >>> >> -- >> Mud mailing list >> Mud@ietf.org >> https://www.ietf.org/mailman/listinfo/mud >> >> -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > > --0000000000009a3d330589de09db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 27 May 2019 at 17:20, Eliot Lear = (elear) <elear@cisco.com> wrot= e:
You can do the same here. What has one advantage: you know the purpose of t= he communication.

Yes, encrypted = traffic inspection is possible in Enterprise networks (acting as TLS proxy)= but not in home networks. If the enforcement point in home network cannot = snoop/inspect DNS traffic, looking into the traffic to the IP address will = not not reveal the domain name with TLS 1.3 and ESNI.

<= div>Cheers,
-Tiru
=C2=A0

Elio= t

On May 27, 2019, at 12:16, tirumal reddy <kondtir@gmail.com> wrote:

On Mon, 27 May 2019 at 15:34, Eliot Lear (elear) <elear@cisco.com> wro= te:
Absolutely true.=C2=A0 And that matters if there is a vas= t quantity of crap on those IPs.=C2=A0 Worth keeping in mind. But this isn= =E2=80=99t do much a MUD problem as more of a General hygiene matter.=C2=A0= You are likely to block IPs with garbage on them regardless of whether MUD is in play.=C2=A0

No, a IP address can serve both benign and malicious domains, just bec= ause a malicious domain is hosted on the same IP address simply blocking th= e IP address is not a good technique, access to benign domains will also be= blocked. Firewalls typically grey-list such IP addresses and inspect the traffic.

-Tiru
=C2=A0

Eliot

On May 27, 2019, at 11:56, tirumal reddy <kondtir@gmail.com> wrote:

If multiple domains are hosted on the same IP address and = the IoT device uses DOH, the enforcement point will=C2=A0not know the domai= n the IoT device is visiting.=C2=A0Further, MUD controller may not even kno= w the=C2=A0DOH server used by the IoT device.=C2=A0

Google supports domain fronting for=C2=A0its DOH server (s= ee https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y).=

Cheers,
-Tiru

On Mon, 27 May 2019 at 13:41, Eliot L= ear (elear) <elear@= cisco.com> wrote:
To add to what Michael said the requirement is for consistency between the = client and the enforcement point. There are several ways to do that with re= gard to DNS names. One is to snoop DNS. Another is for the resolver to coor= dinate with the enforcement point. Arguably the latter is the better approach but requires more work.

The one mechanism that will certainly not work is DOH when the end device i= gnores to resolve are handed to it by DHCP.

Eliot

> On May 27, 2019, at 03:28, Michael Richardson <mcr+ietf@sandelman.ca> wrot= e:
>
>
> In a private email, it was written:
>> Okay, I admit I never realized there was an assumption built into = MUD that
>> the MUD enforcement point would be able to spy on DNS queries. I g= uess I had
>> assumed one could do reverse DNS, and if that meant some lazy bloc= king, so be
>> it.
>
> I don't know if it's an assumption built-in to MUD.
>
> The assumption in MUD is that a rule can be written in MUD that addres= ses
> end points by name, and that if the MUD controller does it's own f= orward
> lookup, that it gets the same results as the IoT device.
> (I wish lookup by reverse worked, and I've long argued that allowi= ng anything
> on the network without useful reverse DNS is a bad thing, but I've= lost that)
>
> Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT dev= ice)
> termination by DNS where the result returned depends upon who asks.=C2= =A0 This is
> done for geolocation and load balancing reasons.=C2=A0 Used to be it w= as all
> RR DNS queries with TTL-0 results, but providers realized that this sc= rewed
> up the caching properties on their servers, and it was better to point= a
> given user/host consistently to an entry server.
>
> If the MUD-controller can query the same recursive caching DNS server = that the
> IoT device will likely get the same answer from the cache.=C2=A0 So we= have a high
> probability of winning.
>
> DNS-o-HTTPS bypasses all that local caching.
>
> I believe that we need to write a "Operational Considerations of = DNS lookups
> in MUD files" document.
>
> --
> 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

--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud
--0000000000009a3d330589de09db-- From nobody Mon May 27 06:03: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 41C83120137 for ; Mon, 27 May 2019 06:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AGgwMxiT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kt9+1EAK 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 5F30qYjOwPB0 for ; Mon, 27 May 2019 06:03:01 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32F5120073 for ; Mon, 27 May 2019 06:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19751; q=dns/txt; s=iport; t=1558962181; x=1560171781; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i3TkSkKURMgtszkikCrPSeCVZe3H3zGY/WBdafPjj5k=; b=AGgwMxiTMMJl5YnP1YbwKHYjNPcthJMcrTf38ErSBWYz4SJ+Ds7Vjb8J pSZQdAgqL2wNJBxYpOWyJmYNwojJ17A2HLKXyRqakFYsiNKCyGm4BchKM sqoz0JpqQhqRhBrg0+5hEE7+/EUabo0X+m7SKvGQnrbZt8jQcUQuZRb7c g=; IronPort-PHdr: =?us-ascii?q?9a23=3A1qWr9xJ0vEiqUy+7GtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCtad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXED/IffwRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAC+3utc/5ldJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUgYBAQsBgT0kLANpVSAECyiEE4NHA455gleJQYkahFCBLhSBEANUCQE?= =?us-ascii?q?BAQwBARgBCgoCAQGBS4J1AheCPiM1CA4BAwEBBAEBAgEEbRwMhUoBAQEDAQE?= =?us-ascii?q?BEBEdAQEsCwEECwIBCBgnAwICAh8GCxQRAgQOBSKDAAGBHU0DDg8BAgwDnEY?= =?us-ascii?q?CgTiIX3GBL4J5AQEFgTIBgRSCNA0Lgg8DBoE0AYs1HReBQD+BEScfgh4uPoI?= =?us-ascii?q?aRwEBAoEjCQESAQlDgl0ygiaJQ4RJhGMglQs9CQKCDYU1f4h9g2QblkmTcIF?= =?us-ascii?q?ajRwCBAIEBQIOAQEFgVABNjYwcXAVOyoBgkGBFnkMF4NNhRSFP3KBKYpzgkM?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.60,519,1549929600"; d="scan'208,217";a="565410597" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2019 13:02:46 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x4RD2jIe001782 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2019 13:02:45 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 08:02:45 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 08:02:44 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 27 May 2019 09:02:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i3TkSkKURMgtszkikCrPSeCVZe3H3zGY/WBdafPjj5k=; b=kt9+1EAKWw+FTnL7ZZ7PA79WOqW/yD5iDW2mTKDETTfQNzxdvebag1Jr6DkKYv9A73uj4QvL0TBU7HOvVL18jn+Vwk4/ZLmlqWMAuNBWmLay0SlZeDDhsV/GEVjq5tSR7pWr6vdeJdyZRUNW04gv7Qjg/XA8uF/rua7HlVgs/+Y= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3781.namprd11.prod.outlook.com (20.178.238.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Mon, 27 May 2019 13:02:42 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56%7]) with mapi id 15.20.1922.021; Mon, 27 May 2019 13:02:42 +0000 From: "Eliot Lear (elear)" To: tirumal reddy CC: Michael Richardson , "mud@ietf.org" Thread-Topic: [Mud] Unique credentials for devices in a home network Thread-Index: AQHVFCuKU8uy2WzIwUG3dhABmH6VcKZ+gQ1egAA7JgCAAAKUr4AAAxCAgAAadSKAABG4AIAAApRP Date: Mon, 27 May 2019 13:02:41 +0000 Message-ID: References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:152b:ecc6:f97f:7d49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aeb589ac-1714-47ca-0f17-08d6e2a39aa0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB3781; x-ms-traffictypediagnostic: BYAPR11MB3781: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(366004)(346002)(376002)(189003)(199004)(5070765005)(236005)(81166006)(81156014)(8676002)(6436002)(54906003)(25786009)(6512007)(54896002)(6306002)(186003)(4326008)(8936002)(6116002)(476003)(2616005)(486006)(46003)(446003)(83716004)(11346002)(71190400001)(71200400001)(5660300002)(36756003)(966005)(86362001)(7736002)(53936002)(102836004)(14454004)(66476007)(73956011)(66946007)(76116006)(91956017)(2906002)(66446008)(64756008)(478600001)(66556008)(606006)(1411001)(440504004)(33656002)(53546011)(229853002)(6916009)(6506007)(68736007)(99286004)(316002)(256004)(6486002)(82746002)(517774005)(76176011)(6246003)(14444005)(222643001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3781; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: k7atmciaMW9euEUEvIb8k9xTOpw27J8d/eeX8WTerhvyjUuK6G9pWjAG+GSu/MfB1jWi41lL+O+feOIaisABrYkOGl4Fn4AMpk+sIb8C18iMzP0cfZfn+SP6WBXCE0hwz4YF8Se8OUUZz6nb1+SU3sVZyh/J8YnaD7UYG23VIcOGMfxRYuDpMCRwYbhlnvAsC06z/mSrmz3JFvEgwFPoEZK7bkK91A3Zie6LgJCQEVDKfYfC3ZYRRwt4GFmZY33LwFAd/o9sj78nKTxPFU3pDc0FZ3dvWJDNZwQrcgbi9WHzK2C3qpoLkMiJeFXx6T85vVwDVi9T/PKII/NMZ2okZgVx0ALgeyKCwk4IfXj34hBCKIKLXKIn93oQwiwoGl3Tr7I3ZfsP3W3Cw1slcshLxEGB2ApcdP0W7ceI8PNCmPk= Content-Type: multipart/alternative; boundary="_000_D82324F95FDC4D23A89EAC8CEBB695A0ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aeb589ac-1714-47ca-0f17-08d6e2a39aa0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2019 13:02:41.9492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: elear@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3781 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com 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: Mon, 27 May 2019 13:03:04 -0000 --_000_D82324F95FDC4D23A89EAC8CEBB695A0ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQgYnV0IHlvdSBjYW4gbWF0Y2ggdGhlIElQIGFkZHJlc3MgdG9vIHF1ZXJ5IHJlc3BvbnNl IHRvIGEgZG9tYWluIG5hbWUgaW4gYSBNVUQgZmlsZSBhbmQgaGF2ZSBhbiB1bmRlcnN0YW5kaW5n IHRoYXQgdGhlIGRldmljZSBpcyBsaWtlbHkgY29tbXVuaWNhdGluZyB3aXRoIHRoYXQgc2l0ZSBh cyBkZXNpZ25lZC4gIFRoYXQgZG9lc27igJl0IG1lYW4gdGhlIGRldmljZSBpc27igJl0IGhhY2tl ZCBhbmQgdGFsa2luZyB0byBhIEJvVCBjbmMgb24gdGhlIHNhbWUgYWRkcmVzcy4gIEJ1dCB0aGVy ZSBpcyBhdCBsZWFzdCBhIGdvb2QgY2hhbmNlIGl04oCZcyBkb2luZyB3aGF0IGl04oCZcyBzdXBw b3NlZCB0byBiZSBkb2luZy4gQXMgb3Bwb3NlZCB0byBhIGdlbmVyYWwgcHVycG9zZSBjb21wdXRl ciwgd2hlcmUgeW91IGdldCBubyBoaW50cy4NCg0KRWxpb3QNCg0KT24gTWF5IDI3LCAyMDE5LCBh dCAxNDo1NCwgdGlydW1hbCByZWRkeSA8a29uZHRpckBnbWFpbC5jb208bWFpbHRvOmtvbmR0aXJA Z21haWwuY29tPj4gd3JvdGU6DQoNCk9uIE1vbiwgMjcgTWF5IDIwMTkgYXQgMTc6MjAsIEVsaW90 IExlYXIgKGVsZWFyKSA8ZWxlYXJAY2lzY28uY29tPG1haWx0bzplbGVhckBjaXNjby5jb20+PiB3 cm90ZToNCllvdSBjYW4gZG8gdGhlIHNhbWUgaGVyZS4gV2hhdCBoYXMgb25lIGFkdmFudGFnZTog eW91IGtub3cgdGhlIHB1cnBvc2Ugb2YgdGhlIGNvbW11bmljYXRpb24uDQoNClllcywgZW5jcnlw dGVkIHRyYWZmaWMgaW5zcGVjdGlvbiBpcyBwb3NzaWJsZSBpbiBFbnRlcnByaXNlIG5ldHdvcmtz IChhY3RpbmcgYXMgVExTIHByb3h5KSBidXQgbm90IGluIGhvbWUgbmV0d29ya3MuIElmIHRoZSBl bmZvcmNlbWVudCBwb2ludCBpbiBob21lIG5ldHdvcmsgY2Fubm90IHNub29wL2luc3BlY3QgRE5T IHRyYWZmaWMsIGxvb2tpbmcgaW50byB0aGUgdHJhZmZpYyB0byB0aGUgSVAgYWRkcmVzcyB3aWxs IG5vdCBub3QgcmV2ZWFsIHRoZSBkb21haW4gbmFtZSB3aXRoIFRMUyAxLjMgYW5kIEVTTkkuDQoN CkNoZWVycywNCi1UaXJ1DQoNCg0KRWxpb3QNCg0KT24gTWF5IDI3LCAyMDE5LCBhdCAxMjoxNiwg dGlydW1hbCByZWRkeSA8a29uZHRpckBnbWFpbC5jb208bWFpbHRvOmtvbmR0aXJAZ21haWwuY29t Pj4gd3JvdGU6DQoNCk9uIE1vbiwgMjcgTWF5IDIwMTkgYXQgMTU6MzQsIEVsaW90IExlYXIgKGVs ZWFyKSA8ZWxlYXJAY2lzY28uY29tPG1haWx0bzplbGVhckBjaXNjby5jb20+PiB3cm90ZToNCkFi c29sdXRlbHkgdHJ1ZS4gIEFuZCB0aGF0IG1hdHRlcnMgaWYgdGhlcmUgaXMgYSB2YXN0IHF1YW50 aXR5IG9mIGNyYXAgb24gdGhvc2UgSVBzLiAgV29ydGgga2VlcGluZyBpbiBtaW5kLiBCdXQgdGhp cyBpc27igJl0IGRvIG11Y2ggYSBNVUQgcHJvYmxlbSBhcyBtb3JlIG9mIGEgR2VuZXJhbCBoeWdp ZW5lIG1hdHRlci4gIFlvdSBhcmUgbGlrZWx5IHRvIGJsb2NrIElQcyB3aXRoIGdhcmJhZ2Ugb24g dGhlbSByZWdhcmRsZXNzIG9mIHdoZXRoZXIgTVVEIGlzIGluIHBsYXkuDQoNCk5vLCBhIElQIGFk ZHJlc3MgY2FuIHNlcnZlIGJvdGggYmVuaWduIGFuZCBtYWxpY2lvdXMgZG9tYWlucywganVzdCBi ZWNhdXNlIGEgbWFsaWNpb3VzIGRvbWFpbiBpcyBob3N0ZWQgb24gdGhlIHNhbWUgSVAgYWRkcmVz cyBzaW1wbHkgYmxvY2tpbmcgdGhlIElQIGFkZHJlc3MgaXMgbm90IGEgZ29vZCB0ZWNobmlxdWUs IGFjY2VzcyB0byBiZW5pZ24gZG9tYWlucyB3aWxsIGFsc28gYmUgYmxvY2tlZC4gRmlyZXdhbGxz IHR5cGljYWxseSBncmV5LWxpc3Qgc3VjaCBJUCBhZGRyZXNzZXMgYW5kIGluc3BlY3QgdGhlIHRy YWZmaWMuDQoNCi1UaXJ1DQoNCg0KRWxpb3QNCg0KT24gTWF5IDI3LCAyMDE5LCBhdCAxMTo1Niwg dGlydW1hbCByZWRkeSA8a29uZHRpckBnbWFpbC5jb208bWFpbHRvOmtvbmR0aXJAZ21haWwuY29t Pj4gd3JvdGU6DQoNCklmIG11bHRpcGxlIGRvbWFpbnMgYXJlIGhvc3RlZCBvbiB0aGUgc2FtZSBJ UCBhZGRyZXNzIGFuZCB0aGUgSW9UIGRldmljZSB1c2VzIERPSCwgdGhlIGVuZm9yY2VtZW50IHBv aW50IHdpbGwgbm90IGtub3cgdGhlIGRvbWFpbiB0aGUgSW9UIGRldmljZSBpcyB2aXNpdGluZy4g RnVydGhlciwgTVVEIGNvbnRyb2xsZXIgbWF5IG5vdCBldmVuIGtub3cgdGhlIERPSCBzZXJ2ZXIg dXNlZCBieSB0aGUgSW9UIGRldmljZS4NCg0KR29vZ2xlIHN1cHBvcnRzIGRvbWFpbiBmcm9udGlu ZyBmb3IgaXRzIERPSCBzZXJ2ZXIgKHNlZSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL2RvaC85NU10d1RTVXhjU1ZDVUN4amFCaHB4MG05OFkpLg0KDQpDaGVlcnMsDQotVGly dQ0KDQpPbiBNb24sIDI3IE1heSAyMDE5IGF0IDEzOjQxLCBFbGlvdCBMZWFyIChlbGVhcikgPGVs ZWFyQGNpc2NvLmNvbTxtYWlsdG86ZWxlYXJAY2lzY28uY29tPj4gd3JvdGU6DQpUbyBhZGQgdG8g d2hhdCBNaWNoYWVsIHNhaWQgdGhlIHJlcXVpcmVtZW50IGlzIGZvciBjb25zaXN0ZW5jeSBiZXR3 ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBlbmZvcmNlbWVudCBwb2ludC4gVGhlcmUgYXJlIHNldmVy YWwgd2F5cyB0byBkbyB0aGF0IHdpdGggcmVnYXJkIHRvIEROUyBuYW1lcy4gT25lIGlzIHRvIHNu b29wIEROUy4gQW5vdGhlciBpcyBmb3IgdGhlIHJlc29sdmVyIHRvIGNvb3JkaW5hdGUgd2l0aCB0 aGUgZW5mb3JjZW1lbnQgcG9pbnQuIEFyZ3VhYmx5IHRoZSBsYXR0ZXIgaXMgdGhlIGJldHRlciBh cHByb2FjaCBidXQgcmVxdWlyZXMgbW9yZSB3b3JrLg0KDQpUaGUgb25lIG1lY2hhbmlzbSB0aGF0 IHdpbGwgY2VydGFpbmx5IG5vdCB3b3JrIGlzIERPSCB3aGVuIHRoZSBlbmQgZGV2aWNlIGlnbm9y ZXMgdG8gcmVzb2x2ZSBhcmUgaGFuZGVkIHRvIGl0IGJ5IERIQ1AuDQoNCkVsaW90DQoNCj4gT24g TWF5IDI3LCAyMDE5LCBhdCAwMzoyOCwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E8bWFpbHRvOm1jciUyQmlldGZAc2FuZGVsbWFuLmNhPj4gd3JvdGU6DQo+DQo+DQo+ IEluIGEgcHJpdmF0ZSBlbWFpbCwgaXQgd2FzIHdyaXR0ZW46DQo+PiBPa2F5LCBJIGFkbWl0IEkg bmV2ZXIgcmVhbGl6ZWQgdGhlcmUgd2FzIGFuIGFzc3VtcHRpb24gYnVpbHQgaW50byBNVUQgdGhh dA0KPj4gdGhlIE1VRCBlbmZvcmNlbWVudCBwb2ludCB3b3VsZCBiZSBhYmxlIHRvIHNweSBvbiBE TlMgcXVlcmllcy4gSSBndWVzcyBJIGhhZA0KPj4gYXNzdW1lZCBvbmUgY291bGQgZG8gcmV2ZXJz ZSBETlMsIGFuZCBpZiB0aGF0IG1lYW50IHNvbWUgbGF6eSBibG9ja2luZywgc28gYmUNCj4+IGl0 Lg0KPg0KPiBJIGRvbid0IGtub3cgaWYgaXQncyBhbiBhc3N1bXB0aW9uIGJ1aWx0LWluIHRvIE1V RC4NCj4NCj4gVGhlIGFzc3VtcHRpb24gaW4gTVVEIGlzIHRoYXQgYSBydWxlIGNhbiBiZSB3cml0 dGVuIGluIE1VRCB0aGF0IGFkZHJlc3Nlcw0KPiBlbmQgcG9pbnRzIGJ5IG5hbWUsIGFuZCB0aGF0 IGlmIHRoZSBNVUQgY29udHJvbGxlciBkb2VzIGl0J3Mgb3duIGZvcndhcmQNCj4gbG9va3VwLCB0 aGF0IGl0IGdldHMgdGhlIHNhbWUgcmVzdWx0cyBhcyB0aGUgSW9UIGRldmljZS4NCj4gKEkgd2lz aCBsb29rdXAgYnkgcmV2ZXJzZSB3b3JrZWQsIGFuZCBJJ3ZlIGxvbmcgYXJndWVkIHRoYXQgYWxs b3dpbmcgYW55dGhpbmcNCj4gb24gdGhlIG5ldHdvcmsgd2l0aG91dCB1c2VmdWwgcmV2ZXJzZSBE TlMgaXMgYSBiYWQgdGhpbmcsIGJ1dCBJJ3ZlIGxvc3QgdGhhdCkNCj4NCj4gR29vZ2xlLCBBa2Ft YWksIEZhY2Vib29rLCBBbWF6b24sIEF6dXJlLCBldGMuIGFsbCBwcm92aWRlIGZvciAoSW9UIGRl dmljZSkNCj4gdGVybWluYXRpb24gYnkgRE5TIHdoZXJlIHRoZSByZXN1bHQgcmV0dXJuZWQgZGVw ZW5kcyB1cG9uIHdobyBhc2tzLiAgVGhpcyBpcw0KPiBkb25lIGZvciBnZW9sb2NhdGlvbiBhbmQg bG9hZCBiYWxhbmNpbmcgcmVhc29ucy4gIFVzZWQgdG8gYmUgaXQgd2FzIGFsbA0KPiBSUiBETlMg cXVlcmllcyB3aXRoIFRUTC0wIHJlc3VsdHMsIGJ1dCBwcm92aWRlcnMgcmVhbGl6ZWQgdGhhdCB0 aGlzIHNjcmV3ZWQNCj4gdXAgdGhlIGNhY2hpbmcgcHJvcGVydGllcyBvbiB0aGVpciBzZXJ2ZXJz LCBhbmQgaXQgd2FzIGJldHRlciB0byBwb2ludCBhDQo+IGdpdmVuIHVzZXIvaG9zdCBjb25zaXN0 ZW50bHkgdG8gYW4gZW50cnkgc2VydmVyLg0KPg0KPiBJZiB0aGUgTVVELWNvbnRyb2xsZXIgY2Fu IHF1ZXJ5IHRoZSBzYW1lIHJlY3Vyc2l2ZSBjYWNoaW5nIEROUyBzZXJ2ZXIgdGhhdCB0aGUNCj4g SW9UIGRldmljZSB3aWxsIGxpa2VseSBnZXQgdGhlIHNhbWUgYW5zd2VyIGZyb20gdGhlIGNhY2hl LiAgU28gd2UgaGF2ZSBhIGhpZ2gNCj4gcHJvYmFiaWxpdHkgb2Ygd2lubmluZy4NCj4NCj4gRE5T LW8tSFRUUFMgYnlwYXNzZXMgYWxsIHRoYXQgbG9jYWwgY2FjaGluZy4NCj4NCj4gSSBiZWxpZXZl IHRoYXQgd2UgbmVlZCB0byB3cml0ZSBhICJPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyBvZiBE TlMgbG9va3Vwcw0KPiBpbiBNVUQgZmlsZXMiIGRvY3VtZW50Lg0KPg0KPiAtLQ0KPiBNaWNoYWVs IFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyJTJCSUVURkBzYW5k ZWxtYW4uY2E+PiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQo+IC09IElQdjYgSW9UIGNvbnN1 bHRpbmcgPS0NCj4NCj4NCj4NCj4gLS0NCj4gTXVkIG1haWxpbmcgbGlzdA0KPiBNdWRAaWV0Zi5v cmc8bWFpbHRvOk11ZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tdWQNCg0KLS0NCk11ZCBtYWlsaW5nIGxpc3QNCk11ZEBpZXRmLm9yZzxtYWlsdG86 TXVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQN Ci0tDQpNdWQgbWFpbGluZyBsaXN0DQpNdWRAaWV0Zi5vcmc8bWFpbHRvOk11ZEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVkDQotLQ0KTXVkIG1haWxp bmcgbGlzdA0KTXVkQGlldGYub3JnPG1haWx0bzpNdWRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211ZA0KLS0NCk11ZCBtYWlsaW5nIGxpc3QNCk11ZEBp ZXRmLm9yZzxtYWlsdG86TXVkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tdWQNCg== --_000_D82324F95FDC4D23A89EAC8CEBB695A0ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpS aWdodCBidXQgeW91IGNhbiBtYXRjaCB0aGUgSVAgYWRkcmVzcyB0b28gcXVlcnkgcmVzcG9uc2Ug dG8gYSBkb21haW4gbmFtZSBpbiBhIE1VRCBmaWxlIGFuZCBoYXZlIGFuIHVuZGVyc3RhbmRpbmcg dGhhdCB0aGUgZGV2aWNlIGlzIGxpa2VseSBjb21tdW5pY2F0aW5nIHdpdGggdGhhdCBzaXRlIGFz IGRlc2lnbmVkLiAmbmJzcDtUaGF0IGRvZXNu4oCZdCBtZWFuIHRoZSBkZXZpY2UgaXNu4oCZdCBo YWNrZWQgYW5kIHRhbGtpbmcgdG8gYSBCb1QgY25jIG9uIHRoZQ0KIHNhbWUgYWRkcmVzcy4gJm5i c3A7QnV0IHRoZXJlIGlzIGF0IGxlYXN0IGEgZ29vZCBjaGFuY2UgaXTigJlzIGRvaW5nIHdoYXQg aXTigJlzIHN1cHBvc2VkIHRvIGJlIGRvaW5nLiBBcyBvcHBvc2VkIHRvIGEgZ2VuZXJhbCBwdXJw b3NlIGNvbXB1dGVyLCB3aGVyZSB5b3UgZ2V0IG5vIGhpbnRzLiZuYnNwOzxicj4NCjxicj4NCjxk aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSIgZGlyPSJsdHIiPkVsaW90PC9kaXY+DQo8ZGl2IGRp cj0ibHRyIj48YnI+DQpPbiBNYXkgMjcsIDIwMTksIGF0IDE0OjU0LCB0aXJ1bWFsIHJlZGR5ICZs dDs8YSBocmVmPSJtYWlsdG86a29uZHRpckBnbWFpbC5jb20iPmtvbmR0aXJAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj5PbiBNb24s IDI3IE1heSAyMDE5IGF0IDE3OjIwLCBFbGlvdCBMZWFyIChlbGVhcikgJmx0OzxhIGhyZWY9Im1h aWx0bzplbGVhckBjaXNjby5jb20iPmVsZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFw eCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1 dG8iPllvdSBjYW4gZG8gdGhlIHNhbWUgaGVyZS4gV2hhdCBoYXMgb25lIGFkdmFudGFnZTogeW91 IGtub3cgdGhlIHB1cnBvc2Ugb2YgdGhlIGNvbW11bmljYXRpb24uPGJyPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIGVuY3J5cHRlZCB0cmFmZmlj IGluc3BlY3Rpb24gaXMgcG9zc2libGUgaW4gRW50ZXJwcmlzZSBuZXR3b3JrcyAoYWN0aW5nIGFz IFRMUyBwcm94eSkgYnV0IG5vdCBpbiBob21lIG5ldHdvcmtzLiBJZiB0aGUgZW5mb3JjZW1lbnQg cG9pbnQgaW4gaG9tZSBuZXR3b3JrIGNhbm5vdCBzbm9vcC9pbnNwZWN0IEROUyB0cmFmZmljLCBs b29raW5nIGludG8gdGhlIHRyYWZmaWMgdG8gdGhlIElQIGFkZHJlc3Mgd2lsbCBub3Qgbm90IHJl dmVhbA0KIHRoZSBkb21haW4gbmFtZSB3aXRoIFRMUyAxLjMgYW5kIEVTTkkuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2Pi1UaXJ1PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwy MDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjxkaXYgaWQ9Imdt YWlsLW1fLTE4NDMwNjQ4NjY2Nzc3MTI2MjlBcHBsZU1haWxTaWduYXR1cmUiIGRpcj0ibHRyIj5F bGlvdDwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KT24gTWF5IDI3LCAyMDE5LCBhdCAxMjox NiwgdGlydW1hbCByZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvbmR0aXJAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+a29uZHRpckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPk9uIE1vbiwgMjcgTWF5IDIwMTkgYXQgMTU6MzQs IEVsaW90IExlYXIgKGVsZWFyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVsZWFyQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmVsZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xp ZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPkFi c29sdXRlbHkgdHJ1ZS4mbmJzcDsgQW5kIHRoYXQgbWF0dGVycyBpZiB0aGVyZSBpcyBhIHZhc3Qg cXVhbnRpdHkgb2YgY3JhcCBvbiB0aG9zZSBJUHMuJm5ic3A7IFdvcnRoIGtlZXBpbmcgaW4gbWlu ZC4gQnV0IHRoaXMgaXNu4oCZdCBkbyBtdWNoIGEgTVVEIHByb2JsZW0gYXMgbW9yZSBvZiBhIEdl bmVyYWwgaHlnaWVuZSBtYXR0ZXIuJm5ic3A7IFlvdSBhcmUgbGlrZWx5IHRvIGJsb2NrIElQcyB3 aXRoIGdhcmJhZ2Ugb24gdGhlbSByZWdhcmRsZXNzDQogb2Ygd2hldGhlciBNVUQgaXMgaW4gcGxh eS4mbmJzcDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5v LCBhIElQIGFkZHJlc3MgY2FuIHNlcnZlIGJvdGggYmVuaWduIGFuZCBtYWxpY2lvdXMgZG9tYWlu cywganVzdCBiZWNhdXNlIGEgbWFsaWNpb3VzIGRvbWFpbiBpcyBob3N0ZWQgb24gdGhlIHNhbWUg SVAgYWRkcmVzcyBzaW1wbHkgYmxvY2tpbmcgdGhlIElQIGFkZHJlc3MgaXMgbm90IGEgZ29vZCB0 ZWNobmlxdWUsIGFjY2VzcyB0byBiZW5pZ24gZG9tYWlucyB3aWxsIGFsc28gYmUgYmxvY2tlZC4g RmlyZXdhbGxzIHR5cGljYWxseSBncmV5LWxpc3QNCiBzdWNoIElQIGFkZHJlc3NlcyBhbmQgaW5z cGVjdCB0aGUgdHJhZmZpYy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1UaXJ1PGJy Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xp ZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPg0K PGRpdj48YnI+DQo8ZGl2IGlkPSJnbWFpbC1tXy0xODQzMDY0ODY2Njc3NzEyNjI5Z21haWwtbV8z MTM2Mjg5NTY4MDA1MzczNzY1QXBwbGVNYWlsU2lnbmF0dXJlIiBkaXI9Imx0ciI+DQpFbGlvdDwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KT24gTWF5IDI3LCAyMDE5LCBhdCAxMTo1NiwgdGly dW1hbCByZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvbmR0aXJAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+a29uZHRpckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0i bHRyIj4NCjxkaXYgZGlyPSJsdHIiPklmIG11bHRpcGxlIGRvbWFpbnMgYXJlIGhvc3RlZCBvbiB0 aGUgc2FtZSBJUCBhZGRyZXNzIGFuZCB0aGUgSW9UIGRldmljZSB1c2VzIERPSCwgdGhlIGVuZm9y Y2VtZW50IHBvaW50IHdpbGwmbmJzcDtub3Qga25vdyB0aGUgZG9tYWluIHRoZSBJb1QgZGV2aWNl IGlzIHZpc2l0aW5nLiZuYnNwO0Z1cnRoZXIsIE1VRCBjb250cm9sbGVyIG1heSBub3QgZXZlbiBr bm93IHRoZSZuYnNwO0RPSCBzZXJ2ZXIgdXNlZCBieSB0aGUgSW9UIGRldmljZS4mbmJzcDs8L2Rp dj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+R29vZ2xlIHN1 cHBvcnRzIGRvbWFpbiBmcm9udGluZyBmb3ImbmJzcDtpdHMgRE9IIHNlcnZlciAoc2VlIDxhIGhy ZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZG9oLzk1TXR3VFNVeGNT VkNVQ3hqYUJocHgwbTk4WSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9kb2gvOTVNdHdUU1V4Y1NWQ1VDeGphQmhweDBtOThZPC9hPikuPGJy Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2 Pg0KPGRpdj4tVGlydTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIDI3IE1h eSAyMDE5IGF0IDEzOjQxLCBFbGlvdCBMZWFyIChlbGVhcikgJmx0OzxhIGhyZWY9Im1haWx0bzpl bGVhckBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5lbGVhckBjaXNjby5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwy MDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NClRvIGFkZCB0byB3aGF0IE1pY2hhZWwgc2FpZCB0 aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQg dGhlIGVuZm9yY2VtZW50IHBvaW50LiBUaGVyZSBhcmUgc2V2ZXJhbCB3YXlzIHRvIGRvIHRoYXQg d2l0aCByZWdhcmQgdG8gRE5TIG5hbWVzLiBPbmUgaXMgdG8gc25vb3AgRE5TLiBBbm90aGVyIGlz IGZvciB0aGUgcmVzb2x2ZXIgdG8gY29vcmRpbmF0ZSB3aXRoIHRoZSBlbmZvcmNlbWVudCBwb2lu dC4NCiBBcmd1YWJseSB0aGUgbGF0dGVyIGlzIHRoZSBiZXR0ZXIgYXBwcm9hY2ggYnV0IHJlcXVp cmVzIG1vcmUgd29yay4gPGJyPg0KPGJyPg0KVGhlIG9uZSBtZWNoYW5pc20gdGhhdCB3aWxsIGNl cnRhaW5seSBub3Qgd29yayBpcyBET0ggd2hlbiB0aGUgZW5kIGRldmljZSBpZ25vcmVzIHRvIHJl c29sdmUgYXJlIGhhbmRlZCB0byBpdCBieSBESENQLjxicj4NCjxicj4NCkVsaW90PGJyPg0KPGJy Pg0KJmd0OyBPbiBNYXkgMjcsIDIwMTksIGF0IDAzOjI4LCBNaWNoYWVsIFJpY2hhcmRzb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptY3IlMkJpZXRmQHNhbmRlbG1hbi5jYSIgdGFyZ2V0PSJfYmxhbmsi Pm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBJbiBhIHByaXZhdGUgZW1haWwsIGl0IHdhcyB3cml0dGVuOjxicj4N CiZndDsmZ3Q7IE9rYXksIEkgYWRtaXQgSSBuZXZlciByZWFsaXplZCB0aGVyZSB3YXMgYW4gYXNz dW1wdGlvbiBidWlsdCBpbnRvIE1VRCB0aGF0PGJyPg0KJmd0OyZndDsgdGhlIE1VRCBlbmZvcmNl bWVudCBwb2ludCB3b3VsZCBiZSBhYmxlIHRvIHNweSBvbiBETlMgcXVlcmllcy4gSSBndWVzcyBJ IGhhZDxicj4NCiZndDsmZ3Q7IGFzc3VtZWQgb25lIGNvdWxkIGRvIHJldmVyc2UgRE5TLCBhbmQg aWYgdGhhdCBtZWFudCBzb21lIGxhenkgYmxvY2tpbmcsIHNvIGJlPGJyPg0KJmd0OyZndDsgaXQu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG9uJ3Qga25vdyBpZiBpdCdzIGFuIGFzc3VtcHRpb24g YnVpbHQtaW4gdG8gTVVELjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgYXNzdW1wdGlvbiBpbiBN VUQgaXMgdGhhdCBhIHJ1bGUgY2FuIGJlIHdyaXR0ZW4gaW4gTVVEIHRoYXQgYWRkcmVzc2VzPGJy Pg0KJmd0OyBlbmQgcG9pbnRzIGJ5IG5hbWUsIGFuZCB0aGF0IGlmIHRoZSBNVUQgY29udHJvbGxl ciBkb2VzIGl0J3Mgb3duIGZvcndhcmQ8YnI+DQomZ3Q7IGxvb2t1cCwgdGhhdCBpdCBnZXRzIHRo ZSBzYW1lIHJlc3VsdHMgYXMgdGhlIElvVCBkZXZpY2UuPGJyPg0KJmd0OyAoSSB3aXNoIGxvb2t1 cCBieSByZXZlcnNlIHdvcmtlZCwgYW5kIEkndmUgbG9uZyBhcmd1ZWQgdGhhdCBhbGxvd2luZyBh bnl0aGluZzxicj4NCiZndDsgb24gdGhlIG5ldHdvcmsgd2l0aG91dCB1c2VmdWwgcmV2ZXJzZSBE TlMgaXMgYSBiYWQgdGhpbmcsIGJ1dCBJJ3ZlIGxvc3QgdGhhdCk8YnI+DQomZ3Q7IDxicj4NCiZn dDsgR29vZ2xlLCBBa2FtYWksIEZhY2Vib29rLCBBbWF6b24sIEF6dXJlLCBldGMuIGFsbCBwcm92 aWRlIGZvciAoSW9UIGRldmljZSk8YnI+DQomZ3Q7IHRlcm1pbmF0aW9uIGJ5IEROUyB3aGVyZSB0 aGUgcmVzdWx0IHJldHVybmVkIGRlcGVuZHMgdXBvbiB3aG8gYXNrcy4mbmJzcDsgVGhpcyBpczxi cj4NCiZndDsgZG9uZSBmb3IgZ2VvbG9jYXRpb24gYW5kIGxvYWQgYmFsYW5jaW5nIHJlYXNvbnMu Jm5ic3A7IFVzZWQgdG8gYmUgaXQgd2FzIGFsbDxicj4NCiZndDsgUlIgRE5TIHF1ZXJpZXMgd2l0 aCBUVEwtMCByZXN1bHRzLCBidXQgcHJvdmlkZXJzIHJlYWxpemVkIHRoYXQgdGhpcyBzY3Jld2Vk PGJyPg0KJmd0OyB1cCB0aGUgY2FjaGluZyBwcm9wZXJ0aWVzIG9uIHRoZWlyIHNlcnZlcnMsIGFu ZCBpdCB3YXMgYmV0dGVyIHRvIHBvaW50IGE8YnI+DQomZ3Q7IGdpdmVuIHVzZXIvaG9zdCBjb25z aXN0ZW50bHkgdG8gYW4gZW50cnkgc2VydmVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiB0aGUg TVVELWNvbnRyb2xsZXIgY2FuIHF1ZXJ5IHRoZSBzYW1lIHJlY3Vyc2l2ZSBjYWNoaW5nIEROUyBz ZXJ2ZXIgdGhhdCB0aGU8YnI+DQomZ3Q7IElvVCBkZXZpY2Ugd2lsbCBsaWtlbHkgZ2V0IHRoZSBz YW1lIGFuc3dlciBmcm9tIHRoZSBjYWNoZS4mbmJzcDsgU28gd2UgaGF2ZSBhIGhpZ2g8YnI+DQom Z3Q7IHByb2JhYmlsaXR5IG9mIHdpbm5pbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEROUy1vLUhU VFBTIGJ5cGFzc2VzIGFsbCB0aGF0IGxvY2FsIGNhY2hpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgdG8gd3JpdGUgYSAmcXVvdDtPcGVyYXRpb25hbCBDb25z aWRlcmF0aW9ucyBvZiBETlMgbG9va3Vwczxicj4NCiZndDsgaW4gTVVEIGZpbGVzJnF1b3Q7IGRv Y3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTWljaGFlbCBSaWNoYXJk c29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJTJCSUVURkBzYW5kZWxtYW4uY2EiIHRhcmdldD0i X2JsYW5rIj5tY3ImIzQzO0lFVEZAc2FuZGVsbWFuLmNhPC9hPiZndDssIFNhbmRlbG1hbiBTb2Z0 d2FyZSBXb3Jrczxicj4NCiZndDsgLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LTxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBNdWQgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86TXVkQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+TXVkQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQ8L2E+PGJyPg0K PGJyPg0KLS0gPGJyPg0KTXVkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpNdWRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5NdWRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWQiIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXVkPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4+ LS0gPC9zcGFuPjxicj4NCjxzcGFuPk11ZCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+ PGEgaHJlZj0ibWFpbHRvOk11ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk11ZEBpZXRmLm9y ZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tdWQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL211ZDwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48 c3Bhbj4tLSA8L3NwYW4+PGJyPg0KPHNwYW4+TXVkIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8 c3Bhbj48YSBocmVmPSJtYWlsdG86TXVkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TXVkQGll dGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL211ZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXVkPC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bh bj4tLSA8L3NwYW4+PGJyPg0KPHNwYW4+TXVkIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bh bj48YSBocmVmPSJtYWlsdG86TXVkQGlldGYub3JnIj5NdWRAaWV0Zi5vcmc8L2E+PC9zcGFuPjxi cj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXVkIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211ZDwvYT48L3NwYW4+ PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D82324F95FDC4D23A89EAC8CEBB695A0ciscocom_-- From nobody Mon May 27 06:29:29 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 649E512015F for ; Mon, 27 May 2019 06:29:26 -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 yy9-3FoEfwQW for ; Mon, 27 May 2019 06:29:24 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 3EB7912001A for ; Mon, 27 May 2019 06:29:24 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id k8so144630iot.1 for ; Mon, 27 May 2019 06:29:24 -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=WfASlFlYhhAjcVAjYs+l2S+brIN88xahxCptNRy1xds=; b=EkYqx3nK9SV0YACC5w6ofwM3d9uBh8mpjsUj1KZSR0o3NtyETVo25PzRR27h6Cflb3 4anYhmmAx2eZGn/qvigE8kxPNS20dDwRdo0+oSZJZM5LB0g4O3Y/D4OdF9GeUA01Laef vFv0sqA0Mil0b8dVKjDvoyYfjK5FWZCeoLWYSPaaXFw+9a8zQCC5yOOL7CfzLuZCkXoz hkmy2cBGoQ6Dmcbv4AK1ZsbwuNM7rg7ifo27XgFVv1VSucSB7w/D+sVFdl92no1QiZGc cQTtiql7fd5zkDynuvQUVZlwlzxUE+JZd+KphqVxrojer42E3AwqmJh2Gl1uR1azCulB M9cQ== 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=WfASlFlYhhAjcVAjYs+l2S+brIN88xahxCptNRy1xds=; b=hDxjI/SIDpZynC5berdI4Dy0+w7/N66nOeTKQeGukJzxkYrfgK1rfT+sk3G4IXKQlE cpbzEOJC2I4ZX/7L5X7UWSwldHqDO0sDgjG45fZJZv7b3kVg7HteI7qR6ANB5SPPhfYx UgCtH9L7qG5JoZx5UzxFrvdJjl6zzqYGjpLaCIzc6dxd6YbdT1ZR/kuCVU0LEZNSQOe0 Pnm1fhiup3bRiCtpH9CNkbJ33l2PVapsxfFDSJD9bQ+v8iVNEcI2gwpq5ZVtSzCEfEmM hkCMJsLcPIBOX7pjvsI/bfarEugazojM6izPE8TZHnNaS2FfwM9mdQ/kFhTMZC1rlySa NbyA== X-Gm-Message-State: APjAAAUZxk/g6tSDsqkqp0LPlYLhZKnX5CZVNAVA2BWE12K4yXfhW+RA 7Yz2BHMSD6/31GPw6cFcHJJH22FMgx1NurSPktg= X-Google-Smtp-Source: APXvYqzqFey+cleA4xjmZGICJ2jJARpGlG6oXVqF5eNVQkO3fYHvWTYLYgjGLkLWFwdZsLQEN+QDiBRur9CqqdkHKDA= X-Received: by 2002:a5d:9743:: with SMTP id c3mr1436673ioo.32.1558963763435; Mon, 27 May 2019 06:29:23 -0700 (PDT) MIME-Version: 1.0 References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@cisco.com> In-Reply-To: From: tirumal reddy Date: Mon, 27 May 2019 18:59:11 +0530 Message-ID: To: "Eliot Lear (elear)" Cc: Michael Richardson , "mud@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005671d10589de89e2" 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: Mon, 27 May 2019 13:29:26 -0000 --0000000000005671d10589de89e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 27 May 2019 at 18:33, Eliot Lear (elear) wrote: > Right but you can match the IP address too query response to a domain nam= e > in a MUD file and have an understanding that the device is likely > communicating with that site as designed. That doesn=E2=80=99t mean the = device > isn=E2=80=99t hacked and talking to a BoT cnc on the same address. But t= here is at > least a good chance it=E2=80=99s doing what it=E2=80=99s supposed to be d= oing. As opposed > to a general purpose computer, where you get no hints. > Yup, the MUD file also has to provide the DOH/DOT server used by the IoT device, so both IoT device and MUD controller use the same DNS server. -Tiru > > Eliot > > On May 27, 2019, at 14:54, tirumal reddy wrote: > > On Mon, 27 May 2019 at 17:20, Eliot Lear (elear) wrote: > >> You can do the same here. What has one advantage: you know the purpose o= f >> the communication. >> > > Yes, encrypted traffic inspection is possible in Enterprise networks > (acting as TLS proxy) but not in home networks. If the enforcement point = in > home network cannot snoop/inspect DNS traffic, looking into the traffic t= o > the IP address will not not reveal the domain name with TLS 1.3 and ESNI. > > Cheers, > -Tiru > > >> >> Eliot >> >> On May 27, 2019, at 12:16, tirumal reddy wrote: >> >> On Mon, 27 May 2019 at 15:34, Eliot Lear (elear) wrote= : >> >>> Absolutely true. And that matters if there is a vast quantity of crap >>> on those IPs. Worth keeping in mind. But this isn=E2=80=99t do much a = MUD problem >>> as more of a General hygiene matter. You are likely to block IPs with >>> garbage on them regardless of whether MUD is in play. >>> >> >> No, a IP address can serve both benign and malicious domains, just >> because a malicious domain is hosted on the same IP address simply block= ing >> the IP address is not a good technique, access to benign domains will al= so >> be blocked. Firewalls typically grey-list such IP addresses and inspect = the >> traffic. >> >> -Tiru >> >> >>> >>> Eliot >>> >>> On May 27, 2019, at 11:56, tirumal reddy wrote: >>> >>> If multiple domains are hosted on the same IP address and the IoT devic= e >>> uses DOH, the enforcement point will not know the domain the IoT device= is >>> visiting. Further, MUD controller may not even know the DOH server used= by >>> the IoT device. >>> >>> Google supports domain fronting for its DOH server (see >>> https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y). >>> >>> Cheers, >>> -Tiru >>> >>> On Mon, 27 May 2019 at 13:41, Eliot Lear (elear) >>> wrote: >>> >>>> To add to what Michael said the requirement is for consistency between >>>> the client and the enforcement point. There are several ways to do tha= t >>>> with regard to DNS names. One is to snoop DNS. Another is for the reso= lver >>>> to coordinate with the enforcement point. Arguably the latter is the b= etter >>>> approach but requires more work. >>>> >>>> The one mechanism that will certainly not work is DOH when the end >>>> device ignores to resolve are handed to it by DHCP. >>>> >>>> Eliot >>>> >>>> > On May 27, 2019, at 03:28, Michael Richardson >>>> wrote: >>>> > >>>> > >>>> > In a private email, it was written: >>>> >> Okay, I admit I never realized there was an assumption built into >>>> MUD that >>>> >> the MUD enforcement point would be able to spy on DNS queries. I >>>> guess I had >>>> >> assumed one could do reverse DNS, and if that meant some lazy >>>> blocking, so be >>>> >> it. >>>> > >>>> > I don't know if it's an assumption built-in to MUD. >>>> > >>>> > The assumption in MUD is that a rule can be written in MUD that >>>> addresses >>>> > end points by name, and that if the MUD controller does it's own >>>> forward >>>> > lookup, that it gets the same results as the IoT device. >>>> > (I wish lookup by reverse worked, and I've long argued that allowing >>>> anything >>>> > on the network without useful reverse DNS is a bad thing, but I've >>>> lost that) >>>> > >>>> > Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT >>>> device) >>>> > termination by DNS where the result returned depends upon who asks. >>>> This is >>>> > done for geolocation and load balancing reasons. Used to be it was >>>> all >>>> > RR DNS queries with TTL-0 results, but providers realized that this >>>> screwed >>>> > up the caching properties on their servers, and it was better to >>>> point a >>>> > given user/host consistently to an entry server. >>>> > >>>> > If the MUD-controller can query the same recursive caching DNS serve= r >>>> that the >>>> > IoT device will likely get the same answer from the cache. So we >>>> have a high >>>> > probability of winning. >>>> > >>>> > DNS-o-HTTPS bypasses all that local caching. >>>> > >>>> > I believe that we need to write a "Operational Considerations of DNS >>>> lookups >>>> > in MUD files" document. >>>> > >>>> > -- >>>> > Michael Richardson , Sandelman Software Works >>>> > -=3D IPv6 IoT consulting =3D- >>>> > >>>> > >>>> > >>>> > -- >>>> > Mud mailing list >>>> > Mud@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/mud >>>> >>>> -- >>>> Mud mailing list >>>> Mud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mud >>>> >>> -- >>> Mud mailing list >>> Mud@ietf.org >>> https://www.ietf.org/mailman/listinfo/mud >>> >>> -- >> Mud mailing list >> Mud@ietf.org >> https://www.ietf.org/mailman/listinfo/mud >> >> -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud > > --0000000000005671d10589de89e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 27 May 2019 at 18:33, Eliot Lear = (elear) <elear@cisco.com> wrot= e:
Right but you can match the IP address too query response to a domain name = in a MUD file and have an understanding that the device is likely communica= ting with that site as designed.=C2=A0 That doesn=E2=80=99t mean the device= isn=E2=80=99t hacked and talking to a BoT cnc on the same address.=C2=A0 But there is at least a good chance it=E2=80=99s doing= what it=E2=80=99s supposed to be doing. As opposed to a general purpose co= mputer, where you get no hints.=C2=A0

=
Yup, the MUD file also has to provide the DOH/DOT server used=C2=A0by = the IoT device, so both IoT device and MUD controller use the=C2=A0same DNS= server.=C2=A0=C2=A0

-Tiru
=C2=A0

Eliot=

On May 27, 2019, at 14:54, tirumal reddy <kondtir@gmail.com> wrote:

On Mon, 27 May 2019 at 17:20, Eliot Lear (elear) <elear@cisco.com> wro= te:
You can do the same here. What has one advantage: you kno= w the purpose of the communication.

Yes, encrypted traffic inspection is possible in Enterprise networks (= acting as TLS proxy) but not in home networks. If the enforcement point in = home network cannot snoop/inspect DNS traffic, looking into the traffic to = the IP address will not not reveal the domain name with TLS 1.3 and ESNI.

Cheers,
-Tiru
=C2=A0

Eliot

On May 27, 2019, at 12:16, tirumal reddy <kondtir@gmail.com> wrote:

On Mon, 27 May 2019 at 15:34, Eliot Lear (elear) <elear@cisco.com> wro= te:
Absolutely true.=C2=A0 And that matters if there is a vas= t quantity of crap on those IPs.=C2=A0 Worth keeping in mind. But this isn= =E2=80=99t do much a MUD problem as more of a General hygiene matter.=C2=A0= You are likely to block IPs with garbage on them regardless of whether MUD is in play.=C2=A0

No, a IP address can serve both benign and malicious domains, just bec= ause a malicious domain is hosted on the same IP address simply blocking th= e IP address is not a good technique, access to benign domains will also be= blocked. Firewalls typically grey-list such IP addresses and inspect the traffic.

-Tiru
=C2=A0

Eliot

On May 27, 2019, at 11:56, tirumal reddy <kondtir@gmail.com> wrote:

If multiple domains are hosted on the same IP address and = the IoT device uses DOH, the enforcement point will=C2=A0not know the domai= n the IoT device is visiting.=C2=A0Further, MUD controller may not even kno= w the=C2=A0DOH server used by the IoT device.=C2=A0

Google supports domain fronting for=C2=A0its DOH server (s= ee https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y).=

Cheers,
-Tiru

On Mon, 27 May 2019 at 13:41, Eliot L= ear (elear) <elear@= cisco.com> wrote:
To add to what Michael said the requirement is for consistency between the = client and the enforcement point. There are several ways to do that with re= gard to DNS names. One is to snoop DNS. Another is for the resolver to coor= dinate with the enforcement point. Arguably the latter is the better approach but requires more work.

The one mechanism that will certainly not work is DOH when the end device i= gnores to resolve are handed to it by DHCP.

Eliot

> On May 27, 2019, at 03:28, Michael Richardson <mcr+ietf@sandelman.ca> wrot= e:
>
>
> In a private email, it was written:
>> Okay, I admit I never realized there was an assumption built into = MUD that
>> the MUD enforcement point would be able to spy on DNS queries. I g= uess I had
>> assumed one could do reverse DNS, and if that meant some lazy bloc= king, so be
>> it.
>
> I don't know if it's an assumption built-in to MUD.
>
> The assumption in MUD is that a rule can be written in MUD that addres= ses
> end points by name, and that if the MUD controller does it's own f= orward
> lookup, that it gets the same results as the IoT device.
> (I wish lookup by reverse worked, and I've long argued that allowi= ng anything
> on the network without useful reverse DNS is a bad thing, but I've= lost that)
>
> Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT dev= ice)
> termination by DNS where the result returned depends upon who asks.=C2= =A0 This is
> done for geolocation and load balancing reasons.=C2=A0 Used to be it w= as all
> RR DNS queries with TTL-0 results, but providers realized that this sc= rewed
> up the caching properties on their servers, and it was better to point= a
> given user/host consistently to an entry server.
>
> If the MUD-controller can query the same recursive caching DNS server = that the
> IoT device will likely get the same answer from the cache.=C2=A0 So we= have a high
> probability of winning.
>
> DNS-o-HTTPS bypasses all that local caching.
>
> I believe that we need to write a "Operational Considerations of = DNS lookups
> in MUD files" document.
>
> --
> 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

--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud
--0000000000005671d10589de89e2-- From nobody Mon May 27 10:09: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 C2CE41200BA for ; Mon, 27 May 2019 10:09:07 -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 V09XtRlEuXEs for ; Mon, 27 May 2019 10:09:06 -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 D7F3C1200F1 for ; Mon, 27 May 2019 10:09:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B314380BE; Mon, 27 May 2019 13:08:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 875B6F39; Mon, 27 May 2019 13:09:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 848F0BA2; Mon, 27 May 2019 13:09:03 -0400 (EDT) From: Michael Richardson To: tirumal reddy cc: "Eliot Lear \(elear\)" , "mud\@ietf.org" In-Reply-To: References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@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] 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: Mon, 27 May 2019 17:09:08 -0000 --=-=-= Content-Type: text/plain tirumal reddy wrote: > If multiple domains are hosted on the same IP address and the IoT device uses > DOH, the enforcement point will not know the domain the IoT device is > visiting. Further, MUD controller may not even know the DOH server used by > the IoT device. > Google supports domain fronting for its DOH server (see > https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y). I found that mail message a bit cryptic. I think that the point is that all of the google end-point DC entry points provide DoH services, and we can't tell searches from DNS lookups? There is definitely a tension here between supporting DNS privacy, working around censorship on the Internet, and having security of IoT devices. Do we need to write an Operational BCP for IoT and DNS here? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzsGa8ACgkQgItw+93Q 3WWeUAf/doLG0xdNjKpzv93whkzkQ0mR0iarMmSXOxXasuR4OC8R9yYTEv/7TxLW knAj4XcgrHBmt401CR+QHHlBJcwx+bqK4oE9RqCha/Zk+cxd+XmTCCWYpoeG0+SH W9CLkj5xQTigMl7IzpDDA6zVcvLASxCgq3fGNXycL+m+4/8cNACkf8ot9p9Pge12 MJbpvLZcOX/DwQkHlKZfUWpR3eGcRg0yKZehasF/6ACYLnMerFlzf/J3TTXhN2aK l0wIxdENt4tU3VnitXFHwA9NZ+86U7KFP3LfHC6q5E3MBf7HxxcPEuxXRnj83o2H DMBdwxFPi69QtsJ41fUWOqxS0Expcw== =7YsQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 27 10:13:55 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 CF7A7120044 for ; Mon, 27 May 2019 10:13:54 -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 c4q_JsobAR84 for ; Mon, 27 May 2019 10:13:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE67120020 for ; Mon, 27 May 2019 10:13:53 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B377380BE; Mon, 27 May 2019 13:12:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 14D9AF39; Mon, 27 May 2019 13:13:52 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 12605BA2; Mon, 27 May 2019 13:13:52 -0400 (EDT) From: Michael Richardson To: tirumal reddy cc: "Eliot Lear \(elear\)" , "mud\@ietf.org" In-Reply-To: References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@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] 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: Mon, 27 May 2019 17:13:55 -0000 --=-=-= Content-Type: text/plain tirumal reddy wrote: > No, a IP address can serve both benign and malicious domains, just because a > malicious domain is hosted on the same IP address simply blocking the IP > address is not a good technique, access to benign domains will also be > blocked. Firewalls typically grey-list such IP addresses and inspect the > traffic. Yeah. It's a feature of IPv4 scarcity that multiple domains on the same end point is not unusual. That's a feature if you worry about censorship, and a failure if you worry about malware domains. How we inspect traffic without forced TLS official-MITM I don't know. (What's the polite term for doing this?) In the home MTIM the TLS connection just seems like a terrible thing, and it fails in Enterprises outside of Windows-Group-Policy (including, BYOD, but not limited to BYOD) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzsGs8ACgkQgItw+93Q 3WXhCwf8CCfJQUjDBRh3nUCmG/u4Fgb4fTpf8rUeLpPgTwUYUL1dWAlqP/WYiU0o KARh8xtxS5ET8LP5MzE7zW0V1XmuDR0VxQnVYZJmmSjY11C72t+tYq8kFkM4QHO4 rRata1/fOzpO0TQF6YFfkygjd6AViirUGOlXf6oFAncu4rh4Nik4zFgWAJRQpaxQ mSZeVcNp9pN6aEi2rHE3shS23sIJpgTr6tjLqubqD2WfzI52sKxHNiv662AXxYFP 34zlWnptSRH7RQRElNa0yQZosZKhqvC/bAHUv0pun33vs9ZTFTe9rAfdGNAF2yGa pvqZCuPuJMmXGpQQs9RQcj3L8EDLpw== =MeiX -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 27 10:36:28 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 6CB2A1200C4 for ; Mon, 27 May 2019 10:36:26 -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 6tPKITszcK9X for ; Mon, 27 May 2019 10:36:25 -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 C5637120043 for ; Mon, 27 May 2019 10:36:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5A5C3380BE for ; Mon, 27 May 2019 13:35:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C6805F39; Mon, 27 May 2019 13:36:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C4201BA2 for ; Mon, 27 May 2019 13:36:22 -0400 (EDT) From: Michael Richardson To: "mud\@ietf.org" In-Reply-To: <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@cisco.com> References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com>, <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@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: [Mud] how mud deals with DNS names vs DNS-over-HTTPs 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, 27 May 2019 17:36:26 -0000 --=-=-= Content-Type: text/plain Eliot Lear (elear) wrote: > You can do the same here. What has one advantage: you know the purpose of the > communication. Not understanding you here. (Aren't you supposed to be AFK?) "same here" <- grey list? How do we know the purpose of the communication if an IP has benign and malicious domains on it? I can see that if a MUD file lists "benign.example.com" with IP 2001:db8:85a3::8a2e:370:7334 and badguy.example.com is also on that address. We don't know that of course. Lets say that "victim.example.com" is also on that address. I guess there are several situations here. 1) 2001:db8:85a3::8a2e:370:7334 is the nearest entry to a data center that handles hundreds of domains. It could use SNI to patch connections through, or it could terminate TLS itself. In this case it's not that the system is compromised, it's just that MUD can't protect victim.example.com from compromised IoT devices that also have legit reason to talk to benign.example.com. Operational advice may be: don't do this in IPv6, instead use the richness of the IPv6 space to route a /64 to each TLS DC end point and spread things out. The downside is that is makes censorship much easier too. 2) 2001:db8:85a3::8a2e:370:7334 is the address of only benign.example.com. An attacker compromises benigh.example.com (or the servers behind it), in order to host badguy.example.com, perhaps to put their command and control server there. In this case, it seems that the IoT cloud server has actually been compromised, and the difference in name is inconsequential from a MUD point of view. It's not a MUD problem. 3) 2001:db8:85a3::8a2e:370:7334 is the address of benign.example.com and it *also* (intentionally) provides a DNS-over-HTTPS service for the IoT devices. If the names returned by DoH are the same as would be returned to the MUD controller by regular DNS, then there is no problem. Of course, the DoH server has no real idea what might be returned, nor does the MUD controller. This situation could arise easily if there was some home device from vendor X that wanted to talk to vendor Y's social media system. (Let X={Google,Microsoft,Amazon} and Y=Facebook) It seems we ought to write, "Don't do this". Now, are there other cases to think about? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzsIBYACgkQgItw+93Q 3WVfJQf/Xn6PqxrmwRSPDBJ498kqyKshMlqYvJn/01qrjv77szmAA1J8f8gC+YaG mNm4VNOC2XLykMJqRwCdnO3R25NkoCir6UjJamgPRgdlVQ11DKFYdzFsh9bDQTGf gchJDKqy08xUH+n/zdv0nvaV6As0lRTPVFiyHeoI84gctrEwpWUfePBWaH27cD6U 0MMEIW7+7wSbHo1sWqUNjA551sFxbHYKAFcb7Q1ohqwwvOTr6GSsZ2dOwOMUQ18/ +NT71Rrp+8N9zphb5IF+5GWR2GIFq+h/FVu9ZOZ3CctAIbupqEHS7EJbrREzzdZg KfhLqnAtEFXEgpi4VO4GUICpdwez/g== =ZfKU -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 27 12:34: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 A34DD1200D8 for ; Mon, 27 May 2019 12:34:10 -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, 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 header.b=aht/+B9M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LolCoceR 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 AV9WZj30AiEJ for ; Mon, 27 May 2019 12:34:08 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7C51201A8 for ; Mon, 27 May 2019 12:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4184; q=dns/txt; s=iport; t=1558985647; x=1560195247; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MfrJjGqbVq092OPx9BfN3hEpKpD/UX9OUOc1yfe6i08=; b=aht/+B9Mli/FOIcadiTrPUnL52qCQaM0ttibOE5hfTwfBZlGNERZ4QH/ MFoMH+YWQh80qGJzD4/dtcuv7N9j/QN6rUE2LKdoY0c7AuOrsgLOOsE5B JgSfg3RnOGo3964/754jOao+/mop0Wk07mnPcXrR88gNFhLnPKMESvE7C A=; IronPort-PHdr: =?us-ascii?q?9a23=3A8dWk2RG+ZvvMyi0a41gdjZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efPuYiUgNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQBcOuxc/4UNJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAQBAQsBgT1QA2lVIAQLKIQTg0cDjnqCV5crgUKBEANUCQEBAQwBARg?= =?us-ascii?q?LCgIBAYFLgnUCF4I/IzcGDgEDAQEEAQECAQRtHAyFSgEBAQMBAQEQEREMAQE?= =?us-ascii?q?sCwEECwIBCBgCAiYCAgIlCxUQAgQOBSKDAAGBagMODwECDJ0GAoE4iF9xgS+?= =?us-ascii?q?CeQEBBYJHgjQYgg8JgQwoAYl/gVMXgUA/gTgfgh4uPoJhAQGBJRURgyAygia?= =?us-ascii?q?JQ4I3ghKFA5VICQKCDYU1f4RIiBkbgh9nhX+JXINoomYCBAIEBQIOAQEFgWU?= =?us-ascii?q?iNoEhcBU7KgGCQQmBDniDcIUUhT9ygSmLHoJSAQE?= X-IronPort-AV: E=Sophos;i="5.60,520,1549929600"; d="scan'208";a="282122544" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2019 19:34:06 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x4RJY60t010242 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 May 2019 19:34:06 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 14:34:05 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 May 2019 15:34:04 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 27 May 2019 15:34:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MfrJjGqbVq092OPx9BfN3hEpKpD/UX9OUOc1yfe6i08=; b=LolCoceRni26mrmIPRBHAOFCmFApNGZYfNBgat3eDDF6+9ZlU/pd2eIWqU+qiIKexF4OV6mLexzDOZM5yGVhru5NuB9jy55pTIVg5aUy24JKBYgMUuuqqhBepMNe+HoINgwKBx4o4j/sjg4w0SsQ8rd3LdR9mU11jsZLwbV+B50= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3142.namprd11.prod.outlook.com (20.177.228.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Mon, 27 May 2019 19:34:03 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56%7]) with mapi id 15.20.1922.021; Mon, 27 May 2019 19:34:02 +0000 From: "Eliot Lear (elear)" To: Michael Richardson CC: "mud@ietf.org" Thread-Topic: [Mud] how mud deals with DNS names vs DNS-over-HTTPs Thread-Index: AQHVFLLQSd+Qwh9O8UGM8Mrztnsv8aZ/XOFF Date: Mon, 27 May 2019 19:34:02 +0000 Message-ID: <1821B3E3-A7E0-447A-A1DB-A47EC1197E6E@cisco.com> References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com>, <8BC6C67E-B6B5-4524-B40D-5D0E48476CBF@cisco.com>,<7196.1558978582@localhost> In-Reply-To: <7196.1558978582@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:706a:9f90:5d0e:b08e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5128feec-083d-4e1e-ce23-08d6e2da4640 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB3142; x-ms-traffictypediagnostic: BYAPR11MB3142: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(376002)(346002)(199004)(189003)(14444005)(25786009)(229853002)(256004)(305945005)(6116002)(99286004)(82746002)(81166006)(81156014)(478600001)(83716004)(71200400001)(71190400001)(8676002)(8936002)(2906002)(966005)(446003)(7736002)(36756003)(33656002)(186003)(6246003)(102836004)(6512007)(46003)(6306002)(5660300002)(53546011)(14454004)(6506007)(53936002)(6436002)(6486002)(4326008)(486006)(86362001)(2616005)(11346002)(476003)(45080400002)(64756008)(68736007)(73956011)(66476007)(316002)(66556008)(66946007)(66446008)(76176011)(76116006)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3142; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BXEHI0Rn1cltE7YXdPbrBo0Ceh3wHMkWpMGSaa/SXZmSmbs66AL9mTmxXmYV/VVoTc6EstS78KQWTCeQP9wnriDKK7qrTGmtEpnD0T/nWR4Utcao6oRNcw8aBGORuLdbDrL9hpuv+1j+TRx4brFib6cm9z0zB7TH9IrTkb4X0GHAb1utiulsq4ey42pmx7oOawAl66IY0veskBKWRdQaFvZp1HEQ56eHbFo9KUNhRf1XHKusxtylhMbEwprlkGQurDE0K3Inx+qSCv65PMKDnSwkWifmmog2/48i/Otam1DZDCG/5XwtolC98Un0eE132/mmRe/5DvSuX0wcNTgvYYWtbOaIkEfeLhhcOLVCbizK4FA3JbOy71MSoOJXfob/0fp9kIorfhziH58p2L/upOBpJh+qfHjLi73cTY+IUQw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5128feec-083d-4e1e-ce23-08d6e2da4640 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2019 19:34:02.6585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: elear@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3142 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Mud] how mud deals with DNS names vs DNS-over-HTTPs 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, 27 May 2019 19:34:11 -0000 UGxlYXNlIHNlZSBiZWxvdyAobGltaXRlZCB0eXBpbmcgYW5kIGRpY3RhdGlvbiBpbnRlcmZhY2Up LiANCg0KRWxpb3QNCg0KPiBPbiBNYXkgMjcsIDIwMTksIGF0IDE5OjM3LCBNaWNoYWVsIFJpY2hh cmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+IA0KPiANCj4gRWxpb3QgTGVh ciAoZWxlYXIpIDxlbGVhckBjaXNjby5jb20+IHdyb3RlOg0KPj4gWW91IGNhbiBkbyB0aGUgc2Ft ZSBoZXJlLiBXaGF0IGhhcyBvbmUgYWR2YW50YWdlOiB5b3Uga25vdyB0aGUgcHVycG9zZSBvZiB0 aGUNCj4+IGNvbW11bmljYXRpb24uDQo+IA0KPiBOb3QgdW5kZXJzdGFuZGluZyB5b3UgaGVyZS4g KEFyZW4ndCB5b3Ugc3VwcG9zZWQgdG8gYmUgQUZLPykNCj4gICJzYW1lIGhlcmUiIDwtIGdyZXkg bGlzdD8NCj4gDQoNCnMvd2hhdC9tdWQvDQoNCj4gSG93IGRvIHdlIGtub3cgdGhlIHB1cnBvc2Ug b2YgdGhlIGNvbW11bmljYXRpb24gaWYgYW4gSVAgaGFzIGJlbmlnbg0KPiBhbmQgbWFsaWNpb3Vz IGRvbWFpbnMgb24gaXQ/DQo+IA0KPiBJIGNhbiBzZWUgdGhhdCBpZiBhIE1VRCBmaWxlIGxpc3Rz ICJiZW5pZ24uZXhhbXBsZS5jb20iIHdpdGggSVAgMjAwMTpkYjg6ODVhMzo6OGEyZTozNzA6NzMz NA0KPiBhbmQgYmFkZ3V5LmV4YW1wbGUuY29tIGlzIGFsc28gb24gdGhhdCBhZGRyZXNzLiAgIFdl IGRvbid0IGtub3cgdGhhdCBvZg0KPiBjb3Vyc2UuICBMZXRzIHNheSB0aGF0ICJ2aWN0aW0uZXhh bXBsZS5jb20iIGlzIGFsc28gb24gdGhhdCBhZGRyZXNzLg0KPiANCj4gSSBndWVzcyB0aGVyZSBh cmUgc2V2ZXJhbCBzaXR1YXRpb25zIGhlcmUuDQo+IDEpIDIwMDE6ZGI4Ojg1YTM6OjhhMmU6Mzcw OjczMzQgaXMgdGhlIG5lYXJlc3QgZW50cnkgdG8gYSBkYXRhIGNlbnRlciB0aGF0DQo+ICAgaGFu ZGxlcyBodW5kcmVkcyBvZiBkb21haW5zLiAgSXQgY291bGQgdXNlIFNOSSB0byBwYXRjaCBjb25u ZWN0aW9ucw0KPiAgIHRocm91Z2gsIG9yIGl0IGNvdWxkIHRlcm1pbmF0ZSBUTFMgaXRzZWxmLg0K PiANCj4gICBJbiB0aGlzIGNhc2UgaXQncyBub3QgdGhhdCB0aGUgc3lzdGVtIGlzIGNvbXByb21p c2VkLCBpdCdzIGp1c3QgdGhhdA0KPiAgIE1VRCBjYW4ndCBwcm90ZWN0IHZpY3RpbS5leGFtcGxl LmNvbSBmcm9tIGNvbXByb21pc2VkIElvVCBkZXZpY2VzIHRoYXQNCj4gICBhbHNvIGhhdmUgbGVn aXQgcmVhc29uIHRvIHRhbGsgdG8gYmVuaWduLmV4YW1wbGUuY29tLg0KPiANCg0KTXVkIGlzbuKA mXQgb3V0IHRvIHByb3RlY3QgdmljdGltLmV4YW1wbGUuY29tIHNvIG11Y2ggYXMgaXQgaXMgdGhl IGVuZCBkZXZpY2Ugc2VydmluZyB0aGUgbXVkIHVybC4gDQoNCj4gICBPcGVyYXRpb25hbCBhZHZp Y2UgbWF5IGJlOiBkb24ndCBkbyB0aGlzIGluIElQdjYsIGluc3RlYWQgdXNlIHRoZSByaWNobmVz cw0KPiAgIG9mIHRoZSBJUHY2IHNwYWNlIHRvIHJvdXRlIGEgLzY0IHRvIGVhY2ggVExTIERDIGVu ZCBwb2ludCBhbmQgc3ByZWFkDQo+ICAgdGhpbmdzIG91dC4gIFRoZSBkb3duc2lkZSBpcyB0aGF0 IGlzIG1ha2VzIGNlbnNvcnNoaXAgbXVjaCBlYXNpZXIgdG9vLg0KPiANCj4gMikgMjAwMTpkYjg6 ODVhMzo6OGEyZTozNzA6NzMzNCBpcyB0aGUgYWRkcmVzcyBvZiBvbmx5IGJlbmlnbi5leGFtcGxl LmNvbS4NCj4gICBBbiBhdHRhY2tlciBjb21wcm9taXNlcyBiZW5pZ2guZXhhbXBsZS5jb20gKG9y IHRoZSBzZXJ2ZXJzIGJlaGluZCBpdCksDQo+ICAgaW4gb3JkZXIgdG8gaG9zdCBiYWRndXkuZXhh bXBsZS5jb20sIHBlcmhhcHMgdG8gcHV0IHRoZWlyIGNvbW1hbmQgYW5kDQo+ICAgY29udHJvbCBz ZXJ2ZXIgdGhlcmUuDQo+ICAgSW4gdGhpcyBjYXNlLCBpdCBzZWVtcyB0aGF0IHRoZSBJb1QgY2xv dWQgc2VydmVyIGhhcyBhY3R1YWxseSBiZWVuDQo+ICAgY29tcHJvbWlzZWQsIGFuZCB0aGUgZGlm ZmVyZW5jZSBpbiBuYW1lIGlzIGluY29uc2VxdWVudGlhbCBmcm9tIGEgTVVEDQo+ICAgcG9pbnQg b2Ygdmlldy4NCj4gICBJdCdzIG5vdCBhIE1VRCBwcm9ibGVtLg0KPiANClllcCANCg0KPiAzKSAy MDAxOmRiODo4NWEzOjo4YTJlOjM3MDo3MzM0IGlzIHRoZSBhZGRyZXNzIG9mIGJlbmlnbi5leGFt cGxlLmNvbQ0KPiAgIGFuZCBpdCAqYWxzbyogKGludGVudGlvbmFsbHkpIHByb3ZpZGVzIGEgRE5T LW92ZXItSFRUUFMgc2VydmljZSBmb3IgdGhlDQo+ICAgSW9UIGRldmljZXMuICBJZiB0aGUgbmFt ZXMgcmV0dXJuZWQgYnkgRG9IIGFyZSB0aGUgc2FtZSBhcyB3b3VsZCBiZQ0KPiAgIHJldHVybmVk IHRvIHRoZSBNVUQgY29udHJvbGxlciBieSByZWd1bGFyIEROUywgdGhlbiB0aGVyZSBpcyBubyBw cm9ibGVtLg0KPiANCj4gICBPZiBjb3Vyc2UsIHRoZSBEb0ggc2VydmVyIGhhcyBubyByZWFsIGlk ZWEgd2hhdCBtaWdodCBiZSByZXR1cm5lZCwgbm9yDQo+ICAgZG9lcyB0aGUgTVVEIGNvbnRyb2xs ZXIuICBUaGlzIHNpdHVhdGlvbiBjb3VsZCBhcmlzZSBlYXNpbHkgaWYgdGhlcmUgd2FzDQo+ICAg c29tZSBob21lIGRldmljZSBmcm9tIHZlbmRvciBYIHRoYXQgd2FudGVkIHRvIHRhbGsgdG8gdmVu ZG9yIFkncyBzb2NpYWwNCj4gICBtZWRpYSBzeXN0ZW0uIChMZXQgWD17R29vZ2xlLE1pY3Jvc29m dCxBbWF6b259IGFuZCBZPUZhY2Vib29rKQ0KPiANCj4gICBJdCBzZWVtcyB3ZSBvdWdodCB0byB3 cml0ZSwgIkRvbid0IGRvIHRoaXMiLg0KPiANClllcC4gDQoNCg0KPiBOb3csIGFyZSB0aGVyZSBv dGhlciBjYXNlcyB0byB0aGluayBhYm91dD8NCj4gDQo+IA0KDQpJ4oCZbSBzdXJlIHRoZXJlIGFy ZSBidXQgSSBjYW7igJl0IHRoaW5rIG9mIHRoZW0gYXQgdGhlIG1vbWVudC4gIA0KDQpFbGlvdA0K PiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRl bG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+IA0KPiAN Cj4gDQo+IC0tIA0KPiBNdWQgbWFpbGluZyBsaXN0DQo+IE11ZEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211ZA0K From nobody Mon May 27 23:04: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 2E36B120112 for ; Mon, 27 May 2019 23:04:31 -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 v85MzTKLtR4f for ; Mon, 27 May 2019 23:04:29 -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 4B02E12006A for ; Mon, 27 May 2019 23:04:29 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id p2so14793497iol.2 for ; Mon, 27 May 2019 23:04:29 -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=2sCwvNsIWM8Icn9YdbSuEYb1386ixO1vTXZZUgGf1Ug=; b=jMIqzK9k6nfl6A3QRlL807xkTk1fc2dusyUKqO50+uIaB/jQE4fEg6qZzMl7KRBlt5 EpuBbNH/C3VELn5sCJhhHPkMrmlTKJxjqoLgwnq0KXqjLOrRLTsYwCkdTXmhUkH6Ghcs Pf0nsClN3hSvwOUty/Hk3NyZFtMCed9TqYG6/bgF8/WIIKwSgHsoI04M+upzN2mXptjQ r1k+GxUDQ1CeecKoA7XegOx79H75QeX1kLCMJXAQLn2LstxgncfqHexiWl1+w8Sp5M1x OdzpHK2Qw/3ybxTjtTKnP2Zlrm8rRp3lBNewsPt6B8A4CSrZFOcHIH5ZUa8/8+Cpdm+A zofQ== 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=2sCwvNsIWM8Icn9YdbSuEYb1386ixO1vTXZZUgGf1Ug=; b=gw1ZK9sjgtmDzJLfk2rgV0v8yNOiA86Qs17QDBX739CQmvcm0ocs4IAdy1hFDhAZE8 MNa9POgXPlmLp3XIF2durg4bArxoKTkcDBSFD6sZbr46MelqpdlqodR3VWaxgDsC532h cH5cvkceZEA7HBKGcbD3KzpXPGhl2GdzZzt/ByKDg6jSMxRgxjIZmzR/ktCxm46G3+sP xlGOcs8rI+RrtNvKmd57CBnbBwkJWSaKIOJWl7JFXfnHMQcW6iU3KkDv8gvYalGvU1gS vfeyWHIdHCWsxjSnTpAzzhe/Ipd6zyiKS+WUh3g5yX/bGfFvDK3MAyjYJMUc2sPj2i6t q7FQ== X-Gm-Message-State: APjAAAXWPKHXKQhDWNprh97tgY4PDcE88ifcs7xLZBLDHReCoPynt4oH zHJPCWAOc9laL9tcFuGEYxkKAYQqSKyQjhFUTvo= X-Google-Smtp-Source: APXvYqyrJQV/xBhIAIrd3typ4erOtjN123qAysLwMBGMCLnRTRtu7EoqfFMvtNLzuFsrCy/7uIJl9PodtoGjtYEby1U= X-Received: by 2002:a5d:9743:: with SMTP id c3mr3628272ioo.32.1559023468545; Mon, 27 May 2019 23:04:28 -0700 (PDT) MIME-Version: 1.0 References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <32236.1558976943@localhost> In-Reply-To: <32236.1558976943@localhost> From: tirumal reddy Date: Tue, 28 May 2019 11:34:16 +0530 Message-ID: To: Michael Richardson Cc: "Eliot Lear (elear)" , "mud@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000a10030589ec70bc" 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: Tue, 28 May 2019 06:04:31 -0000 --0000000000000a10030589ec70bc Content-Type: text/plain; charset="UTF-8" On Mon, 27 May 2019 at 22:39, Michael Richardson wrote: > > tirumal reddy wrote: > > If multiple domains are hosted on the same IP address and the IoT > device uses > > DOH, the enforcement point will not know the domain the IoT device is > > visiting. Further, MUD controller may not even know the DOH server > used by > > the IoT device. > > > Google supports domain fronting for its DOH server (see > > > https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y). > > I found that mail message a bit cryptic. > I think that the point is that all of the google end-point DC entry points > provide > DoH services, and we can't tell searches from DNS lookups? > Yup. > > There is definitely a tension here between supporting DNS privacy, working > around censorship on the Internet, and having security of IoT devices. > > Do we need to write an Operational BCP for IoT and DNS here? > Yes, looks useful to me. Cheers, -Tiru > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --0000000000000a10030589ec70bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 27 May 2019 at 22:39, Michael= Richardson <mcr+ietf@sandelm= an.ca> wrote:

tirumal reddy <ko= ndtir@gmail.com> wrote:
=C2=A0 =C2=A0 > If multiple domains are hosted on the same IP address an= d the IoT device uses
=C2=A0 =C2=A0 > DOH, the enforcement point will not know the domain the = IoT device is
=C2=A0 =C2=A0 > visiting. Further, MUD controller may not even know the = DOH server used by
=C2=A0 =C2=A0 > the IoT device.

=C2=A0 =C2=A0 > Google supports domain fronting for its DOH server (see<= br> =C2=A0 =C2=A0 > https://mail= archive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y).

I found that mail message a bit cryptic.
I think that the point is that all of the google end-point DC entry points = provide
DoH services, and we can't tell searches from DNS lookups?

Yup.
=C2=A0

There is definitely a tension here between supporting DNS privacy, working<= br> around censorship on the Internet, and having security of IoT devices.

Do we need to write an Operational BCP for IoT and DNS here?

Yes, looks useful to me.=C2=A0

Cheers,
-Tiru
=C2=A0



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



--0000000000000a10030589ec70bc-- From nobody Mon May 27 23:17:41 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 208A31200A1 for ; Mon, 27 May 2019 23:17:40 -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 5vWQC8QjPrcM for ; Mon, 27 May 2019 23:17:38 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 08EEF12008A for ; Mon, 27 May 2019 23:17:38 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id e184so2191542ite.1 for ; Mon, 27 May 2019 23:17:37 -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=f7vlyyQsmo6BuFuqfAJiXwP54Lp4lOMNr93fy1QDU/Y=; b=hXjJf5s+G5gm2uIje+FYk3MXpgIIjDrJlhnAtiPNqs5CeRMqy47oWVAToRcmuUXWG+ DRen4AHP2s1ipX+NWcrxrLSctT/OKRwFFF0fT2vWfm3/Mkf8e+5atgQ0jfg/dvLu2Pum cC6NzdlQ+MhWUaUNOWHQ/Xbxp0LnGwmAv6aPalN3c44AeYqymOBCP1BB/jMzYj8DYL+u 8LFe0sCZ/1ZIaT5Tmm8pVFfIvjdS4EbjL5mAlXqZofYDPu4CUG6EwUGIRY8lZzAHtghD 1Wwc9u3fdgXI6NzwGAp3pX8JBN/hVJb3F1XQvQba/uu57GggoBbQoharNlgX+F6cy3Wd 1qFg== 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=f7vlyyQsmo6BuFuqfAJiXwP54Lp4lOMNr93fy1QDU/Y=; b=L1etGpMscMw47J4OwkE25PJMElLRHtvI1pmps4/dBLYpKfdu8bGX27O25tOeGNIvG1 v0zfaVO/NWalJepYf10+5exUGHjPnQMlS/Y8/aKZuv/aIq4SiCL8V7FO4MfSg/7BX5bc 0WgyhsD+PjmETF67adipG090ECBfabOZ8plWODASwraDn1JJraFS0SeruUKuakyBzo6M JgnOKY8is1+Nc2kGWl2mdAqA9jCR7yQPJNBMBBAqbqgDn/dPboq8NP6BN8qAZigHR/CV Ot6PuHlWsqNhId9O+Doq2YAlJS4L76w8KJZA7efAuuWaiy3YnUv54GQWCWqxUloeNA7R POdQ== X-Gm-Message-State: APjAAAXMYAJz21OxcdoHhFgS4NuofUtpqg/+Xbz2Z3HlKrV7DIXqxexO o9wIFlXMCUyftbrhLJq11fyZYbr78kwcNDoPkUg= X-Google-Smtp-Source: APXvYqw8N8KlBs8VzyIL8mDB7QzRj2w1dJWRgKv1PuKgyV3M2DtGo5xlIFxKScVkRefCPhqRv3aSYQfghdYw/dNcodA= X-Received: by 2002:a24:798a:: with SMTP id z132mr1839904itc.101.1559024257172; Mon, 27 May 2019 23:17:37 -0700 (PDT) MIME-Version: 1.0 References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> <1004.1558977232@localhost> In-Reply-To: <1004.1558977232@localhost> From: tirumal reddy Date: Tue, 28 May 2019 11:47:25 +0530 Message-ID: To: Michael Richardson Cc: "Eliot Lear (elear)" , "mud@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000b8c2c0589ec9f2e" 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: Tue, 28 May 2019 06:17:40 -0000 --0000000000000b8c2c0589ec9f2e Content-Type: text/plain; charset="UTF-8" On Mon, 27 May 2019 at 22:43, Michael Richardson wrote: > > tirumal reddy wrote: > > No, a IP address can serve both benign and malicious domains, just > because a > > malicious domain is hosted on the same IP address simply blocking > the IP > > address is not a good technique, access to benign domains will also > be > > blocked. Firewalls typically grey-list such IP addresses and inspect > the > > traffic. > > Yeah. It's a feature of IPv4 scarcity that multiple domains on the same end > point is not unusual. That's a feature if you worry about censorship, > and a failure if you worry about malware domains. > > How we inspect traffic without forced TLS official-MITM I don't know. > (What's the polite term for doing this?) > In TLS 1.2 and prior versions, it was easy to identify the domain by inspecting the TLS handshake. It is no longer possible with TLS 1.3, see https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04#section-2.2.1 > > In the home MTIM the TLS connection just seems like a terrible thing, and > it > fails in Enterprises outside of Windows-Group-Policy (including, BYOD, but > not limited to BYOD) > MITM also works for mobile devices and Macs using Mobile Device Management (MDM). But MITM won't work for unmanaged BYOD devices and in home networks. Cheers, -Tiru > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > --0000000000000b8c2c0589ec9f2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, 27 May 2019 at 22:43, Michael Ric= hardson <mcr+ietf@sandelman.c= a> wrote:

tirumal reddy <ko= ndtir@gmail.com> wrote:
=C2=A0 =C2=A0 > No, a IP address can serve both benign and malicious dom= ains, just because a
=C2=A0 =C2=A0 > malicious domain is hosted on the same IP address simply= blocking the IP
=C2=A0 =C2=A0 > address is not a good technique, access to benign domain= s will also be
=C2=A0 =C2=A0 > blocked. Firewalls typically grey-list such IP addresses= and inspect the
=C2=A0 =C2=A0 > traffic.

Yeah. It's a feature of IPv4 scarcity that multiple domains on the same= end
point is not unusual.=C2=A0 That's a feature if you worry about censors= hip,
and a failure if you worry about malware domains.

How we inspect traffic without forced TLS official-MITM I don't know. (What's the polite term for doing this?)

In TLS 1.2 and prior versions, it was easy to identify the domain by = inspecting the TLS handshake. It is no longer possible with TLS 1.3, see=C2= =A0https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04= #section-2.2.1=C2=A0
=C2=A0

In the home MTIM the TLS connection just seems like a terrible thing, and i= t
fails in Enterprises outside of Windows-Group-Policy (including, BYOD, but<= br> not limited to BYOD)

MITM also works fo= r mobile devices and Macs using Mobile Device Management (MDM).=C2=A0=C2=A0=
But MITM won't work for unmanaged BYOD devices and in home n= etworks.

Cheers,
-Tiru

=C2=A0

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-
--0000000000000b8c2c0589ec9f2e-- From nobody Tue May 28 00:04: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 C73BB12015C for ; Tue, 28 May 2019 00:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OvaEtO+Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UaKXsHB+ 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 VvqOE-NfyUnl for ; Tue, 28 May 2019 00:04:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC1B12011C for ; Tue, 28 May 2019 00:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3843; q=dns/txt; s=iport; t=1559027095; x=1560236695; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jS5XC2wiAR18yxi5trNdaHNlQyb5BCDQgUXKneMTrMw=; b=OvaEtO+Z7pfMlILnh1BQdtxr7j3BD3mRzHFjTz4daNNC6VdrUvmKaqeP TkBrEsIiQ7CKezpPwZoH9aR+b0cZvu743/uyZm0HRk/wkUbuetLywt5iR hMuPU3CHi8EcycqMskUInnoVswJF1MbU8GBzYGE6OGavi4+86bIZngvKq o=; IronPort-PHdr: =?us-ascii?q?9a23=3Ag+cmFRbT1kUfj4vV8b6RTCr/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q+bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavnayEzBuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBk3Oxc/5BdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAQBAQsBgT1QA4E+IAQLKIQTg0cDjnmCMolmiRqEUIJSA1QJAQEBDAE?= =?us-ascii?q?BLQIBAYFLgnUCF4JGIzcGDgEDAQEEAQECAQRtHAyFSwIEEhEdAQE3AQ8CAQg?= =?us-ascii?q?EOwMCAgIfERQRAgQOBSKDAIEeTQMdAQKcOwKBOIhfcYEvgnkBAQWCR4IyDQu?= =?us-ascii?q?CDwmBNAGLUheBQD+BEScME4IeLj6CGkcEhGkygiaLXoIuhGOIJY0GPQkCgg2?= =?us-ascii?q?PMYNkG4IfhmaJXINolUqNHAIEAgQFAg4BAQWBZSKBV3AVZQGCQYIPDBeDTYp?= =?us-ascii?q?TcoEpjhABAQ?= X-IronPort-AV: E=Sophos;i="5.60,520,1549929600"; d="scan'208,217";a="345900254" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2019 07:04:52 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x4S74qpW028207 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 May 2019 07:04:52 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 02:04:51 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 02:04:50 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 28 May 2019 02:04:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jS5XC2wiAR18yxi5trNdaHNlQyb5BCDQgUXKneMTrMw=; b=UaKXsHB+/8KgocjRDVUy6qm+G7QXlFPquhRySiVAMPQlDNMDHXFeKlr0avIRoXPs56rGcyPxlLg+VWSMD4YqMal36vJ7psnXUE70LfMO839SLMpg+8naeDBFjFpHwJBETEY9a9jTNH1Mw/XwpgUKxQ2LlgqCzc/GvQClWCqszQ8= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB2808.namprd11.prod.outlook.com (52.135.228.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.22; Tue, 28 May 2019 07:04:49 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::b511:9caf:cfde:ef56%7]) with mapi id 15.20.1943.016; Tue, 28 May 2019 07:04:49 +0000 From: "Eliot Lear (elear)" To: tirumal reddy CC: Michael Richardson , "mud@ietf.org" Thread-Topic: [Mud] Unique credentials for devices in a home network Thread-Index: AQHVFCuKU8uy2WzIwUG3dhABmH6VcKZ+gQ1egAA7JgCAAAKUr4AAAxCAgAB07gCAANrsgIAADT7j Date: Tue, 28 May 2019 07:04:48 +0000 Message-ID: <57331CAC-6CEC-4612-BAA6-806D5393E5D2@cisco.com> References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <9BF2E606-D262-41F5-905C-B7ECCBBB42FF@cisco.com> <1004.1558977232@localhost>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:cd64:c3c:a77b:e98b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44d95ead-dd61-4ede-ecbc-08d6e33ac60f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB2808; x-ms-traffictypediagnostic: BYAPR11MB2808: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(136003)(39860400002)(199004)(189003)(6506007)(53546011)(76176011)(1411001)(81166006)(81156014)(8676002)(6486002)(54906003)(86362001)(5660300002)(8936002)(68736007)(478600001)(4326008)(6916009)(99286004)(66556008)(102836004)(2906002)(66946007)(229853002)(66476007)(64756008)(53936002)(73956011)(76116006)(91956017)(66446008)(14454004)(6246003)(2616005)(71190400001)(46003)(6436002)(82746002)(186003)(71200400001)(54896002)(486006)(446003)(11346002)(476003)(33656002)(4744005)(25786009)(6116002)(7736002)(36756003)(316002)(256004)(236005)(6512007)(83716004)(222643001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2808; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5w9kYDwZFF9i6yD5O5lcrCv683SiYhnpocyAZgwL5qWNcKrf7v8A72HPTuAvt1n/UR3z1WXBoNtNswBXyj3SLF9BAkr3YKj9uTkpbTDCDMwtI8HsGkvrcVQxFxvd4SvU9YqQG8/SIWmnoZhgjjJjwZIruJgqh1jZ9oBHMbVoHe78h5WUHzJmvTIQfvHJAPRJA5h2r92uCeXOBD6eOUedaJu+z7BK57gejQDT/hGJMZTZI1aVzfODOQ3fls8Q32Y7Bruyo3Sj2KqS8cKScpjA+yaSQnQ5RU7vcy8r4Kpc4K5IQEVRdzhhmozazmF2YTRIZL1oyp4J0zGYoWWpYVnSEAmf7Apzr94rUbrOhke8kZP+cocBiLTxgWUD1xoXNF8rHQXvSh8BMO0PhQaTHrQGyey3Us44yIBo12edi3GDezM= Content-Type: multipart/alternative; boundary="_000_57331CAC6CEC4612BAA6806D5393E5D2ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 44d95ead-dd61-4ede-ecbc-08d6e33ac60f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 07:04:48.7756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: elear@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2808 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com 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: Tue, 28 May 2019 07:04:58 -0000 --_000_57331CAC6CEC4612BAA6806D5393E5D2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBiZWxvdy4NCg0KRWxpb3QNCg0KT24gTWF5IDI4LCAyMDE5LCBhdCAwODoxOCwg dGlydW1hbCByZWRkeSA8a29uZHRpckBnbWFpbC5jb208bWFpbHRvOmtvbmR0aXJAZ21haWwuY29t Pj4gd3JvdGU6DQpNSVRNIGFsc28gd29ya3MgZm9yIG1vYmlsZSBkZXZpY2VzIGFuZCBNYWNzIHVz aW5nIE1vYmlsZSBEZXZpY2UgTWFuYWdlbWVudCAoTURNKS4NCkJ1dCBNSVRNIHdvbid0IHdvcmsg Zm9yIHVubWFuYWdlZCBCWU9EIGRldmljZXMgYW5kIGluIGhvbWUgbmV0d29ya3MuDQoNCldoaWxl IEkgYW0gbm90IHJlY29tbWVuZGluZyB0aGlzLCBhbiBBTklNQSBqb2luIHJlZ2lzdHJhciBjb3Vs ZCBzZXJ2ZSB0aGUgZnVuY3Rpb24gb2YgYW4gTURNIHRvIHByb3ZpZGUgcm9vdCBjZXJ0aWZpY2F0 ZXMuICBJdCB3b3VsZCBiZSB1cCB0byB0aGUgbWFudWZhY3R1cmVyIHRvIGFsbG93IHN1Y2ggYSB0 aGluZy4gQW5kIHRoYXQgaXMgd2h5IEkgZG9u4oCZdCByZWNvbW1lbmQgaXRzIHVzZTogeW91IGNh buKAmXQgcmVhc29uYWJseSByZWx5IG9uIHRoZSBmdW5jdGlvbiBiZWluZyB0aGVyZS4NCg0KVGhp cyBoYXZpbmcgYmVlbiBzYWlkLCBlbnRlcnByaXNlIENJU09zIGRvIGhhdmUgY29uY2VybnMgYWJv dXQgZGF0YSBleGZpbHRyYXRpb24gdGhyb3VnaCBJT1QgYmVjYXVzZSB0aGVzZSBkZXZpY2VzIGRv IG5vdCBzdXBwb3J0ICBNRE1zLg0KDQoNCkNoZWVycywNCi1UaXJ1DQoNCg0KDQotLQ0KTWljaGFl bCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jciUyQklFVEZAc2Fu ZGVsbWFuLmNhPj4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KIC09IElQdjYgSW9UIGNvbnN1 bHRpbmcgPS0NCg== --_000_57331CAC6CEC4612BAA6806D5393E5D2ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpQ bGVhc2Ugc2VlIGJlbG93Ljxicj4NCjxicj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSIg ZGlyPSJsdHIiPkVsaW90PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQpPbiBNYXkgMjgsIDIw MTksIGF0IDA4OjE4LCB0aXJ1bWFsIHJlZGR5ICZsdDs8YSBocmVmPSJtYWlsdG86a29uZHRpckBn bWFpbC5jb20iPmtvbmR0aXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KTUlUTSBhbHNv IHdvcmtzIGZvciBtb2JpbGUgZGV2aWNlcyBhbmQgTWFjcyB1c2luZyBNb2JpbGUgRGV2aWNlIE1h bmFnZW1lbnQgKE1ETSkuICZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KPGRpdj5CdXQgTUlUTSB3b24ndCB3b3JrIGZvciB1bm1hbmFnZWQgQllPRCBkZXZpY2VzIGFu ZCBpbiBob21lIG5ldHdvcmtzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hpbGUgSSBhbSBub3QgcmVjb21tZW5k aW5nIHRoaXMsIGFuIEFOSU1BIGpvaW4gcmVnaXN0cmFyIGNvdWxkIHNlcnZlIHRoZSBmdW5jdGlv biBvZiBhbiBNRE0gdG8gcHJvdmlkZSByb290IGNlcnRpZmljYXRlcy4gJm5ic3A7SXQgd291bGQg YmUgdXAgdG8gdGhlIG1hbnVmYWN0dXJlciB0byBhbGxvdyBzdWNoIGEgdGhpbmcuIEFuZCB0aGF0 IGlzIHdoeSBJIGRvbuKAmXQgcmVjb21tZW5kIGl0cyB1c2U6IHlvdSBjYW7igJl0IHJlYXNvbmFi bHkgcmVseSBvbg0KIHRoZSBmdW5jdGlvbiBiZWluZyB0aGVyZS48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoaXMgaGF2aW5nIGJlZW4gc2FpZCwgZW50ZXJwcmlzZSBDSVNPcyBkbyBo YXZlIGNvbmNlcm5zIGFib3V0IGRhdGEgZXhmaWx0cmF0aW9uIHRocm91Z2ggSU9UIGJlY2F1c2Ug dGhlc2UgZGV2aWNlcyBkbyBub3Qgc3VwcG9ydCAmbmJzcDtNRE1zLjwvZGl2Pg0KPGJyPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJz LDwvZGl2Pg0KPGRpdj4tVGlydTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCI+DQo8YnI+DQotLTxicj4NCk1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1jciUyQklFVEZAc2FuZGVsbWFuLmNhIiB0YXJnZXQ9Il9ibGFuayI+bWNy JiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3M8 YnI+DQombmJzcDstPSBJUHY2IElvVCBjb25zdWx0aW5nID0tPGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_57331CAC6CEC4612BAA6806D5393E5D2ciscocom_-- From nobody Wed May 29 02:57:13 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 F00251200A4 for ; Tue, 28 May 2019 15:43:08 -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 Rn3oZ1EJFx25 for ; Tue, 28 May 2019 15:43:07 -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 A8BD3120090 for ; Tue, 28 May 2019 15:43:07 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A27BE38270 for ; Tue, 28 May 2019 18:42:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CFE7FD78; Tue, 28 May 2019 18:43:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CCD5EA8A for ; Tue, 28 May 2019 18:43:05 -0400 (EDT) From: Michael Richardson To: "mud@ietf.org" In-Reply-To: References: <65ef0865853f48779d415becf11eeb9c@BTWP000357.corp.ads> <8343.1558920505@localhost> <9FBB0EEA-A9A7-4CED-A9E2-8BF61DA423EA@cisco.com> <32236.1558976943@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 Date: Tue, 28 May 2019 18:43:05 -0400 Message-ID: <19145.1559083385@localhost> Archived-At: X-Mailman-Approved-At: Wed, 29 May 2019 02:57:12 -0700 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: Tue, 28 May 2019 22:43:09 -0000 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?
How do you identify= an attacker is using the victim device's MAC and IP address to send at= tack traffic (e.g. SYN flood) ?

The problem I am facing is victim devi= ce can possibly get quarantined based on the attack traffic from the attack= er spoofing MAC and IP addresses. Normal traffic from victim's device w= ill end-up getting blocked, and the compromised device in the home can quar= antine other normal devices.

-Tiru