Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 7 Nov 2019 11:47:55 +0000

Hi Sheng,

Could I request 2 slots:

Slot 1:

Name: BRSKI Cloud Registrar
Draft: draft-friel-anima-brski-cloud
Time: 15 mins
Presenters: Owen Friel / Michael Richardson

Slot 2:

Name: ACME Integrations
Drafts: draft-friel-acme-integrations, draft-friel-acme-subdomains
Time: 10 mins
Presenter: Owen Friel

Thanks,
Owen

From: Anima <[email-masked]> On Behalf Of Sheng Jiang
Sent: 08 October 2019 04:56
To: [email-masked]
Cc: [email-masked]
Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore

Hi, all anima,

We have been allocated two sessions of 1.5 + 1 hour for the ANIMA WG meeting for IETF-106 (Singapore). We are now starting to collect agenda items for the sessions. Please send your request for agenda by October 31th, Thursday, to [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>> and both chairs' email. Please note that email to a single chair may cause single-point failure.

As normal, the priority among these non-charter work items would be: these that have active discussion in mail list, then these have submitted drafts, and topics without drafts.

As you may observed, we now have the new WG charter in the place, but still, we have the priority to complete the current WG documents over to adopt any new work.

Please send us (anima-chairs at ietf.org<https://ietf.org/><http://ietf.org%3Chttps/ietf.org/)>)<ietf.org%3chttps:/ietf.org/%3e%3chttp:/ietf.org%3Chttps/ietf.org/)%3e)> requests for time slot by October 31th, Thursday and include:

Name of time slot:

Name of draft(s):

Time requested:

Presenter name(s):

More details about the IETF 106, Montreal can be found at:

https://www.ietf.org/how/meetings/106/

Again, presenters and draft authors please invoke active discussions in the ANIMA list. Mail list is a very good place to discuss and reach consensus on technical issues.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 8 Nov 2019 09:59:22 +0000

Hi, Own,

Thanks for your emails. Your application for time slot are noted. The chairs will allocate time according to the overall received applications. The agenda will be settle down soon.

Best regards,

Sheng

From: Owen Friel (ofriel) [mailto:[email-masked]]
Sent: Thursday, November 07, 2019 7:48 PM
To: Sheng Jiang <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Call for agenda ANIMA @ IETF 106, Singapore

Hi Sheng,

Could I request 2 slots:

Slot 1:

Slot 2:

Name: ACME Integrations

Thanks,
Owen

From: Anima <[email-masked]<mailto:[email-masked]>> On Behalf Of Sheng Jiang
Sent: 08 October 2019 04:56
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore

Hi, all anima,

Name of time slot:

Name of draft(s):

Time requested:

Presenter name(s):

Best regards,

Sheng

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Nov 2019 08:28:44 +0100

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Nov 2019 21:22:46 +1300

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:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Nov 2019 10:14:42 +0100

> known" URI comes from and how the pledge knows it. Is it vendor

It is vendor specific, and it's baked in.

The idea is that we can transform the well-known, but very much proprietary
"call-home" process that many devices use today into something that enables a
transfer of ownership mechanism.

--
]               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: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Nov 2019 08:25:28 +1300

> It is vendor specific, and it's baked in.

Thanks. That was my working assumption, but I suggest stating it up front
in draft-friel-anima-brski-cloud.

> transfer of ownership mechanism.

Understood.

    Brian

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 26 Nov 2019 21:57:12 +0000

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: 25 November 2019 19:25
> To: Michael Richardson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases
> 
> Thanks. That was my working assumption, but I suggest stating it up front in
> draft-friel-anima-brski-cloud.

[ofriel] https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-30#appendix-B states:

"   If no local proxy or registrar service is located using the GRASP
   mechanisms or the above mentioned DNS-based Service Discovery
   methods, the pledge MAY contact a well known manufacturer provided
   bootstrapping server by performing a DNS lookup using a well known
   URI such as "brski-registrar.manufacturer.example.com".  The details
   of the URI are manufacturer specific.  Manufacturers that leverage
   this method on the pledge are responsible for providing the registrar
   service.  Also see Section 2.7."

> 
> > The idea is that we can transform the well-known, but very much
> > proprietary "call-home" process that many devices use today into
> > something that enables a transfer of ownership mechanism.
> 
> Understood.
> 
>     Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2019 11:29:06 +1300

>    service.  Also see Section 2.7."

Fair enough, but that doesn't capture "baked in" and you probably want
manufacturers to be aware of that requirement, especially since this is
distinct from baking in the MUD URL.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Nov 2019 15:06:20 +0100

> service.  Also see Section 2.7."

So, maybe we should quote this literally in anima-brski-cloud's introduction.