Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases

One thing that doesn't seem to be clear either in BRSKI or in
draft-friel-anima-brski-cloud is where the Cloud Registrar's "well
known" URI comes from and how the pledge knows it. Is it vendor
specific or what?

Regards
   Brian (waiting in Changi)

On 24-Nov-19 20:28, Michael Richardson wrote:
> 
> Following up on the discussion at the WG meeting.
> The meeting materials are not yet converted to PDF, but let me attach the
> three pictures, and start three threads on these options, and also I will
> insert the ascii art from the document itself.
> All three:
> 
>     https://github.com/anima-wg/brski-cloud/blob/master/presentations/three-flows.png
> 
> In all cases the Pledge gets some kind of network connectivity.
> This could be an open WiFi, but is more often a cable plugged in with DHCPv4/IPv6.
> 
> 1) Cloud Registrar Redirects
> 
> This is the most non-cloudy of the solutions.  The time sequence is below,
> and the diagram is at:
>   https://github.com/anima-wg/brski-cloud/blob/master/presentations/option-1-cloud-redirect.png
> 
> 
> +--------+            +-----------+              +----------+
> | Pledge |            | Local     |              | Cloud RA |
> |        |            | Registrar |              | / MASA   |
> +--------+            +-----------+              +----------+
>     |                                                 |
>     | 1. Full TLS                                     |
>     |<----------------------------------------------->|
>     |                                                 |
>     | 2. Voucher Request                              |
>     |------------------------------------------------>|
>     |                                                 |
>     | 3. 3xx Location: localra.example.com            |
>     |<------------------------------------------------|
>     |                                                 |
>     | 4. Provisional TLS   |                          |
>     |<-------------------->|                          |
>     |                      |                          |
>     | 5. Voucher Request   |                          |
>     |--------------------->| 6. Voucher Request       |
>     |                      |------------------------->|
>     |                      |                          |
>     |                      | 7. Voucher Response      |
>     |                      |<-------------------------|
>     | 8. Voucher Response  |                          |
>     |<---------------------|                          |
>     |                      |                          |
>     | 9. Validate TLS      |                          |
>     |<-------------------->|                          |
>     |                      |                          |
>     | 10. etc.             |                          |
>     |--------------------->|                          |
> 
> 
> This is the simplest variation, the local registrar is simply not
> discoverable from the location of the Pledge.
> 
> The pledge is told of a way to reach the intended Registrar and process
> proceeds as normal.  Note that the registrar still has to be proven
> by voucher.   There could be attacks on the pledge via DNS.
> 
> This flow does not work at all for devices/manufacturers with poor supply
> integration, as the Cloud RA would have no idea where to redirect the device.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 