Subject: [Anima-bootstrap] schedules and agendas

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2015 11:02:28 -0400

We had discussed moving the Wed. 1400UTC meeting to Wed 1500UTC,
as the nomcom wanted 1400UTC, and 1500UTC was at the time better for
all involved.  HOWEVER, the nomcom had picked a different time to meet
(I'm the past-chair), and 1500UTC has turned in a bad time for Max.

As such, we want to remain at 1400UTC Wednesdays.
We will meet August 12, and probably August 19, as well as
August 26.   We will cancel the meeting September 2.
Subsequent meetings, September 9, ...
(note: August 19 may get cancelled)

We think that have nailed the question about propective ACP vs
some kind of layer-5-ish EAP forwarding mechanism, and concluded that this
descision is outside of our scope, and we'll be opening an issue in the
issue tracker (github? tools.ietf.org? which one are we using chairs?)
towards the signaling design team.

We plan to focus on the EST-level things upwards from this point onwards:
authoriation and authentication blobs/tokens/certificates.

We are looking for a term to describe a bootstrap process that is required
to grow outwards from a central point, like the way tree rings grow.
If you arrange the nodes into a classic tree-representation of a DAG,
then it's a constraint to grow top-to-bottom, but it may be more instructive
to represent the nodes differently.  And the set of links is not restricted
to a DAG.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Aug 2015 03:55:33 +1200

On 06/08/2015 03:02, Michael Richardson wrote:
...
> towards the signaling design team.

Dunno. But the signaling requirements and issues are in the wiki at
http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling%20Requirements
http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling%20Open%20Issues

(oops, I need to re-align the requirements with the numbering used
in the draft.)

If you can phrase the issue precisely, either put it in the wiki directly
or send it to me and I'll do so.

> to grow outwards from a central point, like the way tree rings grow.

Presumably that's an arbitrary point, not one with a big label on it
saying "Centre"?

> to represent the nodes differently.  And the set of links is not restricted

Wait, isn't it a tree anyway (topologically)? A bit hard in ASCII art,
but this is a tree (not a binary tree, of course):

            2 2 2
             \|/
         2    1    2
          \   |   /
        2--1--0--1--2
          /   |   \
         2    1    2
             /|\
            2 2 2

All you need, surely, is a spanning tree over the whole set of nodes.
I need to check this, but I think that GRASP discovery relaying is
defined in a way that effectively builds an implicit spanning tree
across the nodes involved.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2015 15:32:37 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> We think that have nailed the question about propective ACP vs some
    >> kind of layer-5-ish EAP forwarding mechanism, and concluded that this
    >> descision is outside of our scope, and we'll be opening an issue in
    >> the issue tracker (github? tools.ietf.org? which one are we using
    >> chairs?)  towards the signaling design team.

...

    > If you can phrase the issue precisely, either put it in the wiki
    > directly or send it to me and I'll do so.

That's what we are going to do; we could write it into an issue tracker
directly if that's what the chairs want, or edit your wiki, yes.

    >> We plan to focus on the EST-level things upwards from this point
    >> onwards: authoriation and authentication blobs/tokens/certificates.
    >>
    >> We are looking for a term to describe a bootstrap process that is
    >> required to grow outwards from a central point, like the way tree
    >> rings grow.

    > Presumably that's an arbitrary point, not one with a big label on it

So the "Centre" is the place that either *is*, or has connectivity to the
Domain Registry, and which can either talk to all the Vendor specific
MASA, or either *is*, or can talk to the local MASA (for offline operation).

Noting that there could be many such places that could have such
connectivity, so the bootstrap process might look more like rain on a pond.

    >> then it's a constraint to grow top-to-bottom, but it may be more
    >> instructive to represent the nodes differently.  And the set of links
    >> is not restricted to a DAG.

    > but this is a tree (not a binary tree, of course):

Let me annotate your drawing slightly:

          2a-2b-2c
          /  \|/  \
         2d   1    2e
        / \   |   / \
       2f--1--0--1--2g
        \ /   |   \ /
         2h   1    2i
         \   /|\  /
          2j-2k-2l

Note that I've added links around the 2x nodes to connect them,
and thus technically, it's not a DAG anymore, as there might be multiple
ways to go towards 0.  And as I said above, there might be another 0,
located at, say, 2j if another system has an uplink.

    > across the nodes involved.

That will be fine(*) --- but given link-local addresses only, is there some
kind of routing that one does to get messages back to a specific node through
GRASP?

(*)- well, no I think it's not fine; why are we (re-)implementing routing
     protocols in layer-5+?  But, please don't reply here, this part of
     the core of the issue I want to raise, so let me raise it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Aug 2015 23:58:16 +1200

> kind of routing that one does to get messages back to a specific node through

Ah, yes, that's what makes my head hurt when thinking about bootstrapping:
until the ACP has been formed, we only have link-local addresses. But to establish
trust, we need routeable addresses OR specific relaying of the trust messages.

     Brian

> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Aug 2015 10:31:16 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> That will be fine(*) --- but given link-local addresses only, is there
    >> some kind of routing that one does to get messages back to a specific
    >> node through GRASP?

    > Ah, yes, that's what makes my head hurt when thinking about
    > bootstrapping: until the ACP has been formed, we only have link-local
    > addresses. But to establish trust, we need routeable addresses OR
    > specific relaying of the trust messages.

Good, the fact that your head hurts mean that you have understood the
problem properly :-)

We will write this issue up --- we have some suggestions, but first, I think
it needs to go to the WG for an opinion, and out to other parts of the
community for a better understanding of the tradeoffs.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Aug 2015 03:36:10 +1200

I don't want to prolong the pre-discussion, but a discovery/response
sequence in GRASP, even if relayed via link-local addresses,
does include a "Session ID" nonce. We could leverage that prior to
ACP routing (but it isn't safe against an on-path attacker who can
see the nonce).

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 12 Aug 2015 12:53:39 +0000

> -----Original Message-----
> From: Anima-bootstrap [mailto:[email-masked]] On
> Behalf Of Brian E Carpenter
> Sent: 06 August 2015 17:36
> To: Michael Richardson
> Cc: [email-masked]
> Subject: Re: [Anima-bootstrap] issues and trees [was schedules and
> agendas]
> 
> sequence in GRASP, even if relayed via link-local addresses, does include a
> "Session ID" nonce. We could leverage that prior to ACP routing (but it isn't
> safe against an on-path attacker who can see the nonce).
> 
> Regards
>    Brian
> 

Sorry I wasn't on the last calls, so might miss context. But to me, the story isn't that complex. 

A new node can only talk directly to the proxy node, because we only have link local. 
The proxy node has the ACP up which connects it to a registrar. 
Therefore, the new node creates a link local packet, which the proxy relays through the ACP to the registrar, adding some information on its own.

What am I missing?
Michael

> > We will write this issue up --- we have some suggestions, but first, I
> > think it needs to go to the WG for an opinion, and out to other parts
> > of the community for a better understanding of the tradeoffs.
> >
> > --

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Aug 2015 09:14:28 +1200

Michael,

I am just surfacing from 2 weeks vacation in England plus jet lag. See in line below...
> Therefore, the new node creates a link local packet, which the proxy relays through the ACP to the registrar, adding some information on its own.

At the earliest stages of bootstrap it might be necessary to communicate
without the benefit of the ACP, because some nodes needed for a path through
the ACP might themselves not yet have bootstrapped.

Alternatively there would be a constraint that as the ring of trusted
nodes expands, the ACP must expand in lock step, so that new nodes
are never more than one hop from the edge of the ACP.

     Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 14 Aug 2015 06:33:00 +0000

> From: Brian E Carpenter [mailto:[email-masked]]

> Sent: 12 August 2015 23:14

> To: Michael Behringer (mbehring); Michael Richardson

> I am just surfacing from 2 weeks vacation in England plus jet lag. See in line

> below...

> >> Cc: [email-masked]<mailto:[email-masked]>

> >> sequence in GRASP, even if relayed via link-local addresses, does

> >> include a "Session ID" nonce. We could leverage that prior to ACP

> >> routing (but it isn't safe against an on-path attacker who can see the

> nonce).

> >>> Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

> >>>     >> some kind of routing that one does to get messages back to a

> specific

> > Sorry I wasn't on the last calls, so might miss context. But to me, the story

> isn't that complex.

> > A new node can only talk directly to the proxy node, because we only have

> link local.

> > Therefore, the new node creates a link local packet, which the proxy

> relays through the ACP to the registrar, adding some information on its own.

> without the benefit of the ACP, because some nodes needed for a path

> through the ACP might themselves not yet have bootstrapped.

> Alternatively there would be a constraint that as the ring of trusted nodes

> expands, the ACP must expand in lock step, so that new nodes are never

> more than one hop from the edge of the ACP.

I think we clarified this yesterday in the bootstrap meeting, and I now understand what we're discussing about :-)  . So indeed there are two modes, see also the two slides I made to illustrate the difference:

Mode 1:

The "normal ACP" mode: A node is either in a domain or not. If not, it only has link local connectivity and can therefore NOT communicate with nodes further away, specifically not with a registrar that’s further away, nor its MASA server (of its vendor). A new node MUST have a neighbouring node from a domain to bootstrap. In this mode, bootstrap happens in "rings" around already enrolled devices, initially just the (one or several) registrars. We assume that registrars are configured manually for this purpose, so the registrars are not necessarily zero-touch. (We can define such a mode of operation if needed)

(I’m trying to insert the pictures here, not sure how this comes out in IETF mailers…)

Mode 2:

The "prospective ACP" mode, as MichaelR termed it. In that mode, nodes establish a form of communication which is not necessarily trusted, but may give connectivity to a wider network including the Internet. In this mode, all nodes could bootstrap at the same time, since there is a sort of data plane in the "prospective ACL". Once nodes enrol into a domain, they then build the "normal", trusted, domain specific ACP.

(slide 2) In yesterday's discussion we came to the conclusion that the "normal" ACP is sufficient. The advantage of the "prospective" is that you can bootstrap many in parallel, but that is a one-off operation, and probably not that important in most use cases. The prospective ACP has its own complexity (need to set up addressing and routing up front, and, there are a number of security issues with a non-trusted prospective ACP which we'd have to address, especially how to limit Internet access. On the other hand, it allows for a different, direct enrolment process, whereas the in other model you MUST proxy.

So the feeling in yesterday’s call was it’s easier to go with the “normal” ACP model only, use a proxy function for the bootstrap process, and just be clear in the documentation that rollout in a greenfield will go in “rings” around the registrar(s).

MichaelR, Max – let me know if I’m misrepresenting something.

Michael

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 13 Aug 2015 23:45:00 -0700

Btw: Any quick summary or maybe a monthly update from anima-bootstrap
to the WG maling list ? (sorry, was on a whole day customer event so couldn't join).

Cheers
    Toerless

On Fri, Aug 14, 2015 at 06:33:00AM +0000, Michael Behringer (mbehring) wrote:
> The "normal ACP" mode: A node is either in a domain or not. If not, it only has link local connectivity and can therefore NOT communicate with nodes further away, specifically not with a registrar that???s further away, nor its MASA server (of its vendor). A new node MUST have a neighbouring node from a domain to bootstrap. In this mode, bootstrap happens in "rings" around already enrolled devices, initially just the (one or several) registrars. We assume that registrars are configured manually for this purpose, so the registrars are not necessarily zero-touch. (We can define such a mode of operation if needed)
> 
> 
> 
> (I???m trying to insert the pictures here, not sure how this comes out in IETF mailers???)
> 
> 
> 
> 
> 
> 
> Mode 2:
> 
> 
> 
> So the feeling in yesterday???s call was it???s easier to go with the ???normal??? ACP model only, use a proxy function for the bootstrap process, and just be clear in the documentation that rollout in a greenfield will go in ???rings??? around the registrar(s).
> 
> 
> 
> MichaelR, Max ??? let me know if I???m misrepresenting something.
> 
> 
> 
> Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 14 Aug 2015 06:50:24 +0000

Sounds like a good idea. I think Max and MichaelR are best positioned for that, since I missed the first couple of calls. 

Michael

> From: Toerless Eckert (eckert)
> Sent: 14 August 2015 08:45
> To: Michael Behringer (mbehring)
> Cc: Brian E Carpenter; [email-masked]
> > > >>> Brian E Carpenter
> <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> > I think we clarified this yesterday in the bootstrap meeting, and I now
> understand what we're discussing about :-)  . So indeed there are two
> modes, see also the two slides I made to illustrate the difference:
> >
> >
> >
> > Mode 1:
> >
> >
> >
> > The "normal ACP" mode: A node is either in a domain or not. If not, it
> > only has link local connectivity and can therefore NOT communicate
> > with nodes further away, specifically not with a registrar that???s
> > further away, nor its MASA server (of its vendor). A new node MUST
> > have a neighbouring node from a domain to bootstrap. In this mode,
> > bootstrap happens in "rings" around already enrolled devices,
> > initially just the (one or several) registrars. We assume that
> > registrars are configured manually for this purpose, so the registrars
> > are not necessarily zero-touch. (We can define such a mode of
> > operation if needed)
> >
> >
> >
> > The "prospective ACP" mode, as MichaelR termed it. In that mode, nodes
> establish a form of communication which is not necessarily trusted, but may
> give connectivity to a wider network including the Internet. In this mode, all
> nodes could bootstrap at the same time, since there is a sort of data plane in
> the "prospective ACL". Once nodes enrol into a domain, they then build the
> "normal", trusted, domain specific ACP.
> >
> >
> >
> >
> > (slide 2) In yesterday's discussion we came to the conclusion that the
> "normal" ACP is sufficient. The advantage of the "prospective" is that you
> can bootstrap many in parallel, but that is a one-off operation, and probably
> not that important in most use cases. The prospective ACP has its own
> complexity (need to set up addressing and routing up front, and, there are a
> number of security issues with a non-trusted prospective ACP which we'd
> have to address, especially how to limit Internet access. On the other hand,
> it allows for a different, direct enrolment process, whereas the in other
> model you MUST proxy.
> >
> >
> >
> > So the feeling in yesterday???s call was it???s easier to go with the
> ???normal??? ACP model only, use a proxy function for the bootstrap
> process, and just be clear in the documentation that rollout in a greenfield
> will go in ???rings??? around the registrar(s).
> >
> >
> >

---

From: [email-masked]
Date: Fri, 14 Aug 2015 09:56:14 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > Sounds like a good idea. I think Max and MichaelR are best positioned
    > for that, since I missed the first couple of calls.

I have on my todo since two weeks ago to write up the summary of the
layer-2/5 "routing" of join traffic vs a layer-3 solution.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Aug 2015 12:19:52 +1200

> layer-2/5 "routing" of join traffic vs a layer-3 solution.

Michael B and I had an unintentionally-off-list discussion where
I concluded that I prefer his ACP-only model and added:

"Actually that's why we have said that GRASP may
have to run insecure discovery during bootstrap - if you use GRASP to
discover your local proxy, that discovery/response pair will be insecure but
will be link-local only."

If you don't do that, you are faced with having to do off-link GRASP
messages prior to have a valid certificate and that doesn't seem like
a good idea.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 17 Aug 2015 07:44:25 +0000

> Sent: 15 August 2015 02:20

> To: [email-masked]

> On 15/08/2015 01:56, [email-masked]<mailto:[email-masked]> wrote:

> > Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:

> Michael B and I had an unintentionally-off-list discussion where I concluded

> that I prefer his ACP-only model and added:

> "Actually that's why we have said that GRASP may have to run insecure

> discovery during bootstrap - if you use GRASP to discover your local proxy,

> that discovery/response pair will be insecure but will be link-local only."

> messages prior to have a valid certificate and that doesn't seem like a good

> idea.

Yes, I think we're all converging, and this is the model (as I understand it):

Michael