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

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 10 Sep 2019 20:09:05 +0000

FYI, as discussed earlier on the thread, published first cut of the default BRSKI cloud registrar draft.
Owen

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: 10 September 2019 21:03
To: Michael Richardson <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>; Owen Friel (ofriel) <[email-masked]>
Subject: New Version Notification for draft-friel-anima-brski-cloud-00.txt

A new version of I-D, draft-friel-anima-brski-cloud-00.txt
has been successfully submitted by Owen Friel and posted to the IETF repository.

Name:		draft-friel-anima-brski-cloud
Revision:	00
Title:		BRSKI Cloud Registrar
Document date:	2019-09-10
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-friel-anima-brski-cloud-00.txt
Status:         https://datatracker.ietf.org/doc/draft-friel-anima-brski-cloud/
Htmlized:       https://tools.ietf.org/html/draft-friel-anima-brski-cloud-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-friel-anima-brski-cloud

Abstract:
   This document specifies the behaviour of a BRSKI Cloud Registrar, and
   how a pledge can interact with a BRSKI Cloud Registrar when
   bootstrapping.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Sep 2019 16:32:54 +0100

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

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.

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.

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.

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.

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.
   
   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.
   
   A redirect in the form a voucher, is a different thing, pointing the
   pledge to an EST server with which to continue.
   
   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.

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.

-- 
]               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: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 16 Sep 2019 09:49:41 +0000

> From: Iot-onboarding <[email-masked]> On Behalf Of Michael
> Richardson
> Sent: 11 September 2019 16:33
> To: Owen Friel (ofriel) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Iot-onboarding] FW: New Version Notification for draft-friel-
> anima-brski-cloud-00.txt
> 
> 
> 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

> 0) Why isn't is RFC8572 (SZTP) needs to be clearer.

Feel free to PR whatever explanatory text you want here.

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

>    bootstrapped at some other location.

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

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

>    A redirect before request would be based upon the TLS Client Certificate

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.

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

>    pledge to an EST server with which to continue.

Right, that's option 3.

>    separate is that it might be on a per-device basis that it makes the

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

>    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