Re: [Iot-onboarding] FW: New Version Notification for draft-friel-anima-brski-cloud-00.txt

["Owen Friel (ofriel)" <[e-mail]>]

> -----Original Message-----
> From: Iot-onboarding <[e-mail]> On Behalf Of Michael
> Richardson
> Sent: 11 September 2019 16:33
> To: Owen Friel (ofriel) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Iot-onboarding] FW: New Version Notification for draft-friel-
> anima-brski-cloud-00.txt
> 
> 
> Owen Friel (ofriel) <[e-mail]> wrote:
>     > FYI, as discussed earlier on the thread, published first cut of the default
> BRSKI cloud registrar draft.
> 
> Thanks for starting this document.  I will send pull requests once I know where
> you put it...
> 

https://github.com/upros/brski-cloud/blob/master/draft-friel-anima-brski-cloud.md

> 
> I think that there are a few high-level things that need to be clearer.
> 0) Why isn't is RFC8572 (SZTP) needs to be clearer.

Feel free to PR whatever explanatory text you want here.

> 
> 1) what does it mean to onboard to the cloud only.  While it is nice for the
>    IETF to make a standard for a manufacturer to interoperate with itself,
>    we should recognize that we don't need to.  This is basically how every
>    single home-IoT device that calls home works today.

As written, the draft doesn't explicitly talk about bootstrapping against a manufacturer service, it just describes using the cloud registrar to discover the service. There are scenarios where a thing can connect to a manufacturers own service, or can connect to a similar service hosted by an independent operator, with the thing having to discover which deployment model is in use. E.g. cisco phones/video endpoints can connect to cisco hosted and operated services (e.g. Webex or Broadcloud), service provider hosted services, or on-premise private operator managed services. That's a good example of a manufacturer having to interop with  itself and a third party.

> 
> 2) we should clarify some reasons why the device can not find the local
>    registrar.  One reason is that it's not local. I.e. a device being
>    bootstrapped at some other location.

For sure, I can add some example use case test.

> 
> 3) the device already has network connectivity.  Probably from a wire!!!
>    (maybe from an open WiFi though)
>    It's not core enterprise/ISP routing/switching equipment.
> 

Agreed, that's a basic currently unwritten assumption. For things with some kind of UX, it could also be a home wifi network running WPA2/3. Once on the network and with access to the internet, the thing then has to discover its service provider (e.g. core enterprise service exposed on internet via enterprise firewall).

> 4) there is probably a significant difference between a 301 redirect before
>    the voucher request and one that occurs after a voucher is issued.
>    A redirect before request would be based upon the TLS Client Certificate
>    identity.

How can you do a HTTP 301 redirect *before* the thing sends in the voucher request? You cannot do this at the TLS layer based purely on the TLS client cert.

> 
>    A redirect that occured during the voucher-request would be curious, and
>    I'm not sure what purpose it would serve, so I want to ignore this.
> 

Right, and I do not have a redirect before voucher request as an option.

>    A redirect in the form a voucher, is a different thing, pointing the
>    pledge to an EST server with which to continue.

Right, that's option 3.

> 
>    In fact, I would suggest that these are two MAJOR different modes, and
>    might even be different documents/protocols.  The argument for not being
>    separate is that it might be on a per-device basis that it makes the
>    decision.

All 3 options are all variations on HTTP redirect *after* the voucher request is sent.

> 
> 5) I think that this mechanism can never work without some amount of
>    supply-chain integration, otherwise the cloud MASA has no idea who the
>    correct customer is.  This is also implies that it doesn't work for the
>    various "HomeDepot" retail situations.
> 

Correct. This is explicitly documented in https://github.com/upros/brski-cloud/blob/master/draft-friel-anima-brski-cloud.md#pledge-ownership-lookup


> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
>