Re: [OPSAWG] [Mud] Declaring something to be a controller in MUD

Eliot Lear <lear@cisco.com> Wed, 26 June 2019 15:43 UTC

Return-Path: <lear@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F33120100; Wed, 26 Jun 2019 08:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtmIJ2Ts9NWE; Wed, 26 Jun 2019 08:43:05 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC7612003E; Wed, 26 Jun 2019 08:43:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5110; q=dns/txt; s=iport; t=1561563785; x=1562773385; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ZQRBKeQzTVT9jnz3njd9giCaN/RSYI5YJxdHdpZmWLs=; b=dDcyXLryMRPmIAGQxK94OnRO6yU5jgLp6URJGltNVDMWtv8mVBnmBPgv xsxiZk/62V+5UkBy97KpaCDsjNCfyCss2yYsApwdAgBRbZnSqLXifP0ho SikUPWMAgwHNXu6yd+OFyimGWOF7ch/Sb3kacXKbko6ipAJetAeMGsnre g=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BWAAC4kRNd/xbLJq1kGgEBAQEBAgEBAQEHAgEBAQGBZ4MBUQEyIQeEFYh7i18lmmcCBwEBAQkDAQEjDAEBgUuCdQKDIDgTAQMBAQQBAQIBBW2KNwyFSgEBAQMBI1EFBQsLGCoCAlcGE4MiAYF7DwgHpWSBMYVHhF0QgTSBUYokgX+BOAwTgh4uPoJWhHgygiYEjAGHb1qVUAmCGIIegQqDKI0fG4MWlD6UCFiBd4JTiA2DCQIEBgUCFYFnIYFYMxoIGxU7KgGCQQk1ggqDFVSKVT0DMI8rAQE
X-IronPort-AV: E=Sophos;i="5.63,420,1557187200"; d="asc'?scan'208";a="13557855"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2019 15:43:02 +0000
Received: from ams3-vpn-dhcp6365.cisco.com (ams3-vpn-dhcp6365.cisco.com [10.61.88.220]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QFh1PG003375 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jun 2019 15:43:02 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <7DDDF804-8171-4E1E-91C5-CBE4D2965939@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_555F9A05-FBC8-4287-8E2B-E270949473E2"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 26 Jun 2019 17:43:00 +0200
In-Reply-To: <11505.1561563275@localhost>
Cc: opsawg@ietf.org, mud@ietf.org
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com> <1547.1561492346@localhost> <BE16542E-7383-4006-A00F-5000BEC4E68B@cisco.com> <11505.1561563275@localhost>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.88.220, ams3-vpn-dhcp6365.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/3O0uEQznByCAaF9oKgrBMk4nc4k>
Subject: Re: [OPSAWG] [Mud] Declaring something to be a controller in MUD
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 26 Jun 2019 15:43:08 -0000


> On 26 Jun 2019, at 17:34, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> Signed PGP part
> 
> Eliot Lear <lear@cisco.com> wrote:
>>>> In either case, right now the administrator has to manually know and
>>>> populate information, to say - some device 1.2.3.4 is a controller,
>>>> either for MUD URL https://example.com/mud <https://example.com/mud> or
>>>> a class http://example.com/mudclass1 <http://example.com/mudclass1>.
>>>> That can be laborious.  To assist, we are examining ways to have a
>>>> controller declare itself as a candidate controller.  That at least
>>>> provides a hint to the administrator that this particular device is
>>>> capable of serving in a particular role.
>>> 
>>> I think that anything that requires administrator activity to be a fail for
>>> residential use.  It's too complex.
> 
>> There will ALWAYS be a need for an administrator in the enterprise
>> case.  But maybe with the options above we can ease the consumer burden
>> over time.  In the consumer case, you might want an app for initial
>> device admission control anyway, no?  Can we not rely on that
>> interaction as an approval step in this instance?
> 
> I think we'd all like to have a generic app (with an RFC standard API) that
> can onboard any device and can do admission control for any controller.
> I think this is what you are saying as well.

Yes, but I was saying a bit more.  Do you expect to fully automate the inclusion of a controller into a controller class in the home?  How do you envision the full flow looking like?

> 
>>>> One possibility to address this is to incorporate the new RESTful
>>>> endpoint into an ANIMA BRSKI join registrar, which may already be
>>>> exposed.  But that requires that ANIMA BRSKI be in play, which it may
>>>> not.
> 
>>> It is, however, a really good idea for the case where it is in play.
>>> 
>>>> My thinking is that we do this work in two stages.  First handle the
>>>> easy case, which is the MUD file extension, and then figure out how to
>>>> do the app version of this.
>>> 
>>>> Thoughts?
>>> 
>>> yes.
>>> 
> 
>> Was that “yes” to the two stage approach?
> 
> "Yes"   :-)

Okidoke.
> 
> Eliot Lear <lear@cisco.com> wrote:
>>> 1) insist that to user the my-controller connections that the two devices
>>> have to be signed by the "same" entity.  ["same" could mean literal the
>>> same key, the same certificate Issuer/DN,  or something more complex]
>>> 
>>> 2) we could have devices declare in an MUD extension the
>>> DN/certificate/entity which must sign their controller device.
>>> 
>>> 3) (2) above, but with some level of indirection through some URL.
> 
>> Another thought here:
> 
>> We could provide a level of dereference for authorized controllers in
>> the device’s MUD file, in the form of a URL list that would look
>> something like:
> 
>> {  [
>> “controller” : “controller-name"
>> “mud-urls” : [ some mud urls of valid controllers here ]
>> “include” : “https://levelofindirection.example.com” that points to a file that contains a JSON serialization of this grouping
>> }
> 
> yes, this is exactly what I was thinking about.
> 
> Would "mud-urls" / "include" be mutually exclusive?

I don’t see why it would have to be.  But now let’s back up, just to make sure we’re not digging too deep a hole for the application case that Ranga wants to get to.  If the MUD protected device is declaring MUD URLs for MUD controllers and that is what all of this would boil down to, then the app case is really a completely separate mechanism, because apps don’t have MUD-URLs.

If we do a two-stage, then we need a completely separate draft for apps anyway, but I was hoping for some commonality.

Eliot


> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> 
>