Subject: [Mud] updates to diagram

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Jul 2019 09:45:55 -0400

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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2019 14:35:22 -0400

Kent, thanks for the updates.
I will adjust the diagram as you suggest!

I have abandonned the enrollment-roadmap document, and I moved it to
the iot-dir wiki at:

  https://trac.ietf.org/trac/int/wiki/EnrollmentRoadmap

but, the wiki doesn't really help people to edit/update/maintain the diagram,
so it is still in github. I'll change the github to indicate the text is
no longer live.

If you want to update the text in the wiki directly, that would
be appreciated.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2019 16:34:58 -0400

Kent Watsen <[email-masked]> wrote:
    > 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.

For lack of a better term, I'll change "NETCONF" to "SZTP (netconf)"

    > 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.

My intention of the MASA box is that it involves itself in the middle
three items, but not the left-most "ultra-contrained bootstrap"

I have added an equivalent box and marked it "OVIS"

    > Lastly, the bottom row appears to capture statefulness of the
    > connection to MASA.

No, it's not connection to the MASA, the MASA box is just at the bottom
in order to not overlap.   The statefulness is intended to be the
transport that is under the boxes above.
That is, BRSKI is:

     JSON-voucher -over-
     CMS          -over-
     TCP          -over-
     circuit-level

while 6tisch-zero-touch is:
      CBOR              -over-
      COSE              -over-
      EDHOC/LAKE        -over-
      OSCORE            -over-
      stateless CoAP proxy

    > 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.

Agreed... I'm in general assuming that it could be USB/sneaker-net.
I don't know how to represent this well.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Jul 2019 16:39:16 +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 <[email-masked]> wrote:
> 
> 
> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding