Re: [Mud] [Iot-onboarding] updates to diagram

Kent Watsen <kent+ietf@watsen.net> Wed, 24 July 2019 16:39 UTC

Return-Path: <0100016c24d9e7c7-ec4bf062-b68a-403b-b09c-0092a28fb104-000000@amazonses.watsen.net>
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 979871205D7; Wed, 24 Jul 2019 09:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 B_HvmUUkzefg; Wed, 24 Jul 2019 09:39:19 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FC21205D1; Wed, 24 Jul 2019 09:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1563986356; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=zlN4HLbjc9S8yfwdSiI7GrEuOkisRXARv/KTFeaN7PI=; b=SxJ5xNTv3zkV0HAF8P+hfX6MbMRp8viZLQ8o3UDbq2KdD9w0b/wFU/SLpt866NdM eaUUDKQ1t8eaPgDnV6MNGwYY07HUvPg17Zfzo3XsYpgbyZAEgzcovz9uQRkcHMkUtCr w2BpycflnautFn1FUFqkRBHC9HD8+ZaBl+OqUC9I=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016c24d9e7c7-ec4bf062-b68a-403b-b09c-0092a28fb104-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6666BF6-9A8C-4D76-8753-E68750DFBBA5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 24 Jul 2019 16:39:16 +0000
In-Reply-To: <9805.1563803155@dooku.sandelman.ca>
Cc: iot-onboarding@ietf.org, mud@ietf.org, Carsten Bormann <cabo@tzi.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <9805.1563803155@dooku.sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.07.24-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/c8inVCxcNODiVw8vLlF3L7_HCVI>
X-Mailman-Approved-At: Sun, 28 Jul 2019 09:09:05 -0700
Subject: Re: [Mud] [Iot-onboarding] updates to diagram
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 16:39:23 -0000

Hi Michael,

Cool diagram.  A few comments:

The diagram has the label "NETCONF", but this is confusing...while produced by the NETCONF WG, the solution itself does not depend on the NETCONF protocol (though it MAY bootstrap a secure NETCONF session)  From a protocol perspective, it might be more appropriate to have HTTP, or REST, or even RESTCONF.  That said, I think the label "SZTP" is best, as that is the acronyms used in the RFC.

I'm unsure about what is implied by the label MASA.  If just the acronym as defined in the voucher draft, then there should be an arrow pointing to the SZTP box as well.  However, if it implies a functional component (protocol API), then there should be another box called "OVIS" (ownership voucher issuance service) that points to the SZTP box.

Lastly, the bottom row appears to capture statefulness of the connection to MASA.  FWIW, the SZTP solution doesn't necessitate a MASA at the time of the bootstrapping event.  To be clearer, the pledge MAY send a nonce to a local SZTP server, which MAY in turn use that nonce to retrieve an ephemeral voucher from a MASA/OVIS system.

Also, I skimmed the enrollment-roadmap draft and found a couple the SZTP-related sections needing fixing:


Section 5 (call-home ssh/tls/usbkey):

NEW:

   SZTP assumes that the pledge can access a "source of bootstrapping 
   information", which is unbounded, though the draft defines four: removable
   storage devices (e.g., USB key), DNS/mDNS, DHCP v4/v6, and SZTP
   bootstrap server (i.e., HTTPS).   Pledges MAY have well-known SZTP
   bootstrap servers preconfigured during manufacturing, which entails
   Internet connectivity).

   The end-state of the bootstrapping process is the pledge running an initial 
   configuration that may configure the pledge to either open ports to accept
   inbound management connections, or cause the pledge to proactively initiate
   outbound call home management connections (e.g., RFC 8071).



And also Section 7.1 (NETCONF):

NEW

   SZTP is defined in RFC 8572.

   SZTP provides the pledge an initial configuration via a mix of sources
   including removable storage devices (e.g., USB Key,  DHCPv4, DHCPv6,
   mDNS, and SZTP bootstrap servers).  Ownership vouchers are only
   required when the pledge is otherwise unable to trust the network 
   (e.g., using built-in anchors).  

   The initial configuration can be any valid configuration, but typically it is
   the minimal necessary to enable the pledge to establish connectivity to
   its owner's  controller/NMS application.  The pledge MAY open ports for 
   inbound management connections, but it is more typical for the pledge
   to initiate a call home connection (e.g., RFC 8071).

   SZTP is seen as an updated version of TR-69 by some, appropriate
   for configuration of residential appliances which are drop-shiped by
   ISPs or other service providers to homes.  It is also used for other
   deployments including, e.g., campus, retail, kiosks, satellite offices.



Kent



> On Jul 22, 2019, at 9:45 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> I have updated the dia/svg version of the diagram that Eliot put on the
> screen, but some were too far away to see.
> 
> There is also an asciio version, but I think that I will maintain the pretty
> version only.   The key changes is that I inserted RFC8572 and RFC8366
> labels.
> 
> I will think about how to insert BRSKI-TEEP.
> 
> It is at:
>  https://github.com/anima-wg/enrollment-roadmap
> 
> https://github.com/anima-wg/enrollment-roadmap/blob/master/technology-components.svg
> 
> https://github.com/anima-wg/enrollment-roadmap/blob/master/building-block-diagram.txt
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
> 	
> 
> 
> -- 
> Iot-onboarding mailing list
> Iot-onboarding@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding