[OPSAWG] Here's MUD in your eye!
Eliot Lear <lear@cisco.com> Fri, 05 February 2016 07:24 UTC
Return-Path: <lear@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEDC1B38E1 for <opsawg@ietfa.amsl.com>; Thu, 4 Feb 2016 23:24:47 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 4oY_PupkbTZ9 for <opsawg@ietfa.amsl.com>; Thu, 4 Feb 2016 23:24:46 -0800 (PST)
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 A8E131B3896 for <opsawg@ietf.org>; Thu, 4 Feb 2016 23:24:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6637; q=dns/txt; s=iport; t=1454657085; x=1455866685; h=to:from:subject:message-id:date:mime-version; bh=gKRWPT+8HpXp/dt45jsLszqT76W64zv1M3M39U4u2nM=; b=Pg1sITfFE65v0xlYzJ5yImLCtnjdx7JfheqSzAuGLmYiZu+va4GB6/YZ bZ7F/I3Ip4Zb2gUwRq1oPimMkipxlHVMHkLokwK9u43vXRCbzrbSq4VQi xZgnB9ZRn1HOyXBeRueEcmgUR2AlB/xI6Jn8SDCj43vptuetmstmJX0mB A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CsAwD6TLRW/xbLJq1ejVSxDA6BZod+FAEBAQEBAQGBCkEOAYQbVSAdFgsCCwMCAQIBWAgBAYgXoSmPW48RCI5WgyWBOgWHWI8bgn6BZIhugVuEQ4MDhVKKbYNSHgFDgX6BZzuGbYIFgTgBAQE
X-IronPort-AV: E=Sophos;i="5.22,399,1449532800"; d="asc'?scan'208,217";a="632185129"
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-AES256-GCM-SHA384; 05 Feb 2016 07:24:43 +0000
Received: from [10.61.222.230] ([10.61.222.230]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u157Oh1b017245 for <opsawg@ietf.org>; Fri, 5 Feb 2016 07:24:43 GMT
To: opsawg@ietf.org
From: Eliot Lear <lear@cisco.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56B44E3A.9020501@cisco.com>
Date: Fri, 05 Feb 2016 08:24:42 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="5FGDcokFu6AbhgVDUQCkQlNWdP2ub1kot"
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/BxnkGgcuPDZ7OCxAUBjMPc7nwhE>
Subject: [OPSAWG] Here's MUD in your eye!
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 07:24:47 -0000
Hi everyone, For the last few months I've been working on a little effort which I call MUD. It stands for Manufacturer Usage Descriptions, and it focuses on the security of Things. There are already quite a lot things and more on the way (Cisco estimates 50 billion by 2020, and others say more). And there will be many developers/manufacturers of these things. It will be impossible for anyone to really keep track of all of these Things on their own. Developers/manufacturers will be in a good position to tell network administrators what sort of network access these Things require, and as importantly, what sort of network access these things are not intended to have. Consider this simple example : a networked rheostat is unlikely to want to browse CNN. That same rheostat may have a bug. It's also possible for the network to limit who can attack it, so long as the rheostat manufacturer has a means to tell the network what access is needed and what is not. So... what's necessary for all of this to work? 1. A standard way to indicate where a description is stored; 2. A way for the thing to tell the network what it is in such a way that the network can retrieve a description; 3. A schema for the description itself; and optionally 4. Some abstractions that can permit/deny access to certain classes of devices. As an entrée, I've specified a URI as a means to indicate where the desription is (1), IEEE 802.1AR certificates with 802.1X as well as DHCP for getting it from the device (2), and YANG-based XML for (3) and (4). In IETFeze that translates to the following drafts: * draft-lear-mud-framework (a few more lines of text describing the above) * draft-lear-ietf-netmod-mud (the YANG model and the URI specification) * draft-lear-ietf-pkix-mud-extension (a non-critical constraint for the MUD URI); and * draft-lear-ietf-dhc-mud-option (a way to communicate the URI via DHCP) I think you'll find one or two open issues with these drafts (to say the very least), but hopefully you might like the concept. I'm seeking feedback, discussion, collaborators, and perhaps some co-authors on this work. At the very least, I'm sure some people can contribute a humorous pun or two. And please! No mud slinging! ;-) Eliot
- [OPSAWG] Here's MUD in your eye! Eliot Lear