[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