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

[Michael Richardson <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-