Subject: [Anima-bootstrap] BRSKI State Machine

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 14 Oct 2016 14:42:14 +0000

Hi Folks, 

You know that I'm doing a complete thorough top-to-bottom review on the brski draft, but I'm only half-way through right now. (Yes, I'm taking it seriously ;-) 

I'm bringing forward here a single topic that I think is fairly important, so that we can start discussion about that. And that is the state machine. My high-level observation is that I think the draft isn't precise enough yet to allow for independent, interoperable implementations. There are too many "lose ends". 

So, I started looking through the state machine (figure 3), and thought this through in more detail. 

* First of all, one thing isn't coming out clearly (it's there, but somehow not obvious at all): We have three "paths" through the algorithm, and it is the *pledge* that has "hard coded" which paths we're taking: 

1) join any domain (first come first join)  
   --> No MASA required
2) require audit token 
   --> MASA required, audit mode
3) require authentication token 
   --> MASA required, ownership tracking mode

[I really hope we agree on that!!!]

This needs to come out much more clearly. Should this "hard coded" behaviour be changeable under certain conditions? (Don't think so, but...) 
The knee-jerk reaction would be to put this under 3.1, but I think it's more important than that! It should be explained very early, somewhere in 1), maybe in  1.2. Happy to write up some text if the team wants me to (and if we agree ;-) 

* When you try to do a state machine with figure 3, there are a few things that don't quite gel. Main points are: 

- "Identity" isn't really a state in itself. I would argue a pledge USES its identity in the next step. 

- I think we need to bring out more strongly that the state machine needs to track peer and domain. Because, if there is a failure, the pledge should, depending on the failure of course, not try the same domain again, and probably not the same peer either. This isn't coming out today. 
In fact, this is why I liked the "adjacency table" so much that I presented in Berlin (and before): Because there you see much clearer that, if enrolment fails with peer x, you may just move to the next one. As mentioned it's all there, but to a new reader this won't come out clearly, I'm afraid.

- We may want a "reason for rejection" if the domain rejects a device (for all negative cases). In some case, it could be a "wait a minute, I'm currently overloaded", in others "we don't like you in this domain", or "your enrolment mode (see first point) is not acceptable". 
In "real life" this would allow some visual feedback at the install site, so that the engineer knows whether he should wait or can go. 
[note: there may be security reasons to NOT give a reason for rejection, need to think more about this]

- I didn't quite like "imprint" as a state either. To me, the next logical state was "validation". see attached ppt for more details. But bottom line, we need to reflect the 3 "paths" through the algorithm here again. 

- And finally, I suggest we rename "being managed" to "enrolled". Reason is: I'm also drawing up a complete state machine for an ANIMA node, and there I think the main "transition points" between BRSKI and ACP is when the device is "enrolled". Thus I suggest to call the final state in BRSKI "Enrolled", and the first one in ACP the same. (Besides, "being managed" doesn't sound right when we're talking a fully autonomic device.)

In the attached ppt I made those few changes, and I marked with a red star, where I think we need more work before any last call, apart from what  I already mentioned: 

- we need to specify precisely the discovery method, with mDNS field names, and other details. In my head we're using mDNS here, and I *think* we agreed on that? But, we'll need the same method also for the ACP draft: When both nodes have a certificate, they need to discover each other as well. 
I've been haggling with Toerless about this :-)   I think we should take the mDNS insecure discovery into a separate, new draft. This is likely very short, BUT: I think it doesn't really belong in the BRSKI draft (specifically if we use BRSKI also for non-ANIMA environments), neither in the ACP draft (because we also need it in BRSKI). Having a separate draft would be very clean. However I understand (when pushed hard) we may not want to do this for admin reasons. 
Alternatively, we specify the discovery in the ACP draft, and BRSKI refers to it. I like this less, but will not scream murder if others insist. 

So much for now. Still on the full review, but this is pretty high level, and pretty fundamental. Happy to help with text and/or ASCII art if we decide to take on some of these points. 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Oct 2016 08:40:53 +1300

Hi Michael,
On 15/10/2016 03:42, Michael Behringer (mbehring) wrote:
...
> [I really hope we agree on that!!!]

What about the air gap case (no external interaction allowed, by site policy)?
Would there be a simulated MASA in that case? In any case, that is not a choice
that the pledge can make.

...
> - we need to specify precisely the discovery method, with mDNS field names, and other details. In my head we're using mDNS here, and I *think* we agreed on that? 

No, I think we agreed on supporting both mDNS or GRASP discovery; it is of course the
latter hat I've modelled. We have no need of mDNS for GRASP-capable nodes, but we must
support mDNS between the proxy and a non-GRASP-capable pledge. I've got no objection
to also specifying mDNS between the proxy and the registrar, but I think it's
redundant.

Indeed the details have to be specified; I haven't formally written them up for
the GRASP methods but they are embedded in my Python code.
(Again, https://www.cs.auckland.ac.nz/~brian/graspy/brski/)

Rgds
    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 17 Oct 2016 23:05:16 +0000

Thanks for the detailed review notes! They are much appreciated and very timely. I’ll be spending time this week addressing them. 

Responding to the higher level discussion inline, 

> On Oct 14, 2016, at 8:42 AM, Michael Behringer (mbehring) <[email-masked]> wrote:
> 
> Hi Folks, 
> 

For the record: I consider this a security vulnerability but accept that it will take a number of high profile attacks before folks come around to agreeing with me. ;) I recommend against this. 

> [I really hope we agree on that!!!]

Agreed. 

Where #2 and #3 could be seen as a single path with slightly different information in the message from the MASA server; but we’d be quickly be into the weeds of the msg format if we get into that here. 

> - "Identity" isn't really a state in itself. I would argue a pledge USES its identity in the next step. 

From a protocol perspective the pledge completes authentication as part of the TLS handshake and only after that is complete does it ‘request join’. So I called these distinct states. I don’t feel strongly about it though and am open to combining these states. 

> In fact, this is why I liked the "adjacency table" so much that I presented in Berlin (and before): Because there you see much clearer that, if enrolment fails with peer x, you may just move to the…

Yeah, I can see your point that this is buried in the text of 3.1.1 where it is implied that there is a list of "services returned during each query” and in failure the list processing "picks up where it left off” but thats pretty subtle. 

> [note: there may be security reasons to NOT give a reason for rejection, need to think more about this]

I think here we need to provide information about what happened. This is why s5.4 exists to have the pledge send telemetry back to the network that attempted bootstrapping. 

But note this is from the pledge to the domain. The device is assumed to be headless/zero-touch etc so I wasn’t thinking in terms of sending error messages to it. I’m open to doing so though.

> - I didn't quite like "imprint" as a state either. To me, the next logical state was "validation". see attached ppt for more details. But bottom line, we need to reflect the 3 "paths" through the a…

“validation” is a fine thing to call that state. 

> - And finally, I suggest we rename "being managed" to "enrolled". Reason is: I'm also drawing up a complete state machine for an ANIMA node, and there I think the main "transition points" between B…

I think there is a distinction between “obtaining an identity on the domain” and “what i do after I have an identity to be engaged with the domain”. So there are two states here. But yes, “being managed” could be “on the domain” or something. 

> - we need to specify precisely the discovery method, with mDNS field names, and other details. In my head we're using mDNS here, and I *think* we agreed on that? 

yes. with understanding that the proxy to registrar SHOULD be discovered using GRASP for ACP devices. 

> But, we'll need the same method also for the ACP draft: When both nodes have a certificate, they need to discover each other as well. 
> I've been haggling with Toerless about this :-)   I think we should take the mDNS insecure discovery into a separate, new draft.

I don’t follow. mDNS simply *is* insecure. This is important since we can’t establish a secure discovery yet. 

> This is likely very short, BUT: I think it doesn't really belong in the BRSKI draft (specifically if we use BRSKI also for non-ANIMA environments), neither in the ACP draft (because we also need it in BRSKI). Having a separate draft would be very clean. However I understand (when pushed hard) we may not want to do this for admin reasons. 

I think discovery of the proxy must be in this draft. I’m happy to move the proxy’s discovery of the registrar to another draft but I think its ok to recommend GRASP for that connection so I don’t see a problem with that. 

- max

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Oct 2016 12:18:21 +1300

On 18/10/2016 12:05, Max Pritikin (pritikin) wrote:
...
> Yeah, I can see your point that this is buried in the text of 3.1.1 where it is implied that there is a list of "services returned during each query” and in failure the list processing "picks up wh…

What exactly is the "peer" in the above text? I tend to assume it's the proxy.
In that case it seems to me that the discovery process (whether it's mDNS
or GRASP) will discover all available proxies regardless of domain. And then
try them in some order of preference TBD.

Also, all of this needs to work in the absence of an ACP and therefore
of the ACP's adjacency table. That applies to GRASP too, because in order
to perform its various link-local actions, it needs to know which interfaces
it has and which link-local addresses it has. And it learns of its link-local
neighbors as a result of discovery. So while I fully appreciate the value
of the adjacency table, we need to be functional without it.

Rgds
    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 18 Oct 2016 07:33:41 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 17 October 2016 21:41
> To: Michael Behringer (mbehring) <[email-masked]>; anima-
> [email-masked]
> Subject: Re: [Anima-bootstrap] BRSKI State Machine
> 
> Hi Michael,
> > * First of all, one thing isn't coming out clearly (it's there, but somehow not
> obvious at all): We have three "paths" through the algorithm, and it is the
> *pledge* that has "hard coded" which paths we're taking:
> >
> Would there be a simulated MASA in that case? In any case, that is not a
> choice that the pledge can make.

Well, if you can't have external communications, you have two options: 
1) case 1 above. Registrar and CA are local within the airgap zone, all works. With the security caveats that Max makes. 
2) case 3 where the MASA ownership vouchers are created up front, put on a CD ROM, and send into the airgap zone. 
 
Your point is probably: We should explain that. And, I think you're right! Sounds like uses cases of BRSKI. Maybe appendices? 

> ...
> > - we need to specify precisely the discovery method, with mDNS field
> names, and other details. In my head we're using mDNS here, and I *think*
> we agreed on that?
> 
> No, I think we agreed on supporting both mDNS or GRASP discovery; it is of
> course the latter hat I've modelled. We have no need of mDNS for GRASP-
> capable nodes, but we must support mDNS between the proxy and a non-
> GRASP-capable pledge. I've got no objection to also specifying mDNS
> between the proxy and the registrar, but I think it's redundant.

Sigh. I'm a bit lost on what we decided, to be honest... Is that written down somewhere? We need to nail down discovery in two places: 

BRSKI: Pledge needs to find proxy. 
3.1.1 is the place in the BRSKI doc where discovery is specified, and it clearly does NOT say what you said above :-) 
ACP: one ANIMA node needs to find other ANIMA nodes. 
5.2 specifies mDNS today. 

We really need to start nailing this down! 

Michael

> Indeed the details have to be specified; I haven't formally written them up
> for the GRASP methods but they are embedded in my Python code.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 18 Oct 2016 07:51:44 +0000

> From: Max Pritikin (pritikin)
> Sent: 18 October 2016 01:05
> To: Michael Behringer (mbehring) <[email-masked]>
> Cc: [email-masked]
> Thanks for the detailed review notes! They are much appreciated and very
> timely. I’ll be spending time this week addressing them.
> 
> > You know that I'm doing a complete thorough top-to-bottom review on
> > the brski draft, but I'm only half-way through right now. (Yes, I'm
> > taking it seriously ;-)
> >
> > I'm bringing forward here a single topic that I think is fairly important, so
> that we can start discussion about that. And that is the state machine. My
> high-level observation is that I think the draft isn't precise enough yet to
> allow for independent, interoperable implementations. There are too many
> "lose ends".
> >
> For the record: I consider this a security vulnerability but accept that it will
> take a number of high profile attacks before folks come around to agreeing
> with me. ;) I recommend against this.
> 
> > 2) require audit token
> Where #2 and #3 could be seen as a single path with slightly different
> information in the message from the MASA server; but we’d be quickly be
> into the weeds of the msg format if we get into that here.

So this discussion is important to get right before we go to last call on this documents, since a lot of the details depend on those high level choices. I suggest we try to get consensus on how to deal with those 3 cases asap. 

I agree with your observation on 1. We have to make a conscious choice between a) being less secure but quickly deployable, or b) being more secure but requiring more vendor support before being able to "fly". My point is, we're not really making this choice today; while we sort of try to divert from 1) we really allow everything. If we really want to disallow option 1, we should say so. If not, my feeling is after reading the whole thing: we MUST explain all options very clearly in parallel, else there are too many variants and loose ends. 

I'm not sure we can combine 2 and 3 into a single case, although it would be desirable of course. 

In 2) the pledge MUST create and send a nonce (this is explained in 5.1). You cannot audit without a nonce. Freshness is a MUST for audit events. 
In 3) the nonce is optional. And we have a deployment model where we request all authorization tokens up front (potentially at time of purchase), so this will be used. And it is the pledge who decides whether to send a nonce or not, and if it does, the response MUST be fresh. (correct me if I'm wrong). So, really, we actually even have case 3a) and 3b), and we MUST explain that in the "behaviour of a new device". We need to be very clear and explicit... 

Therefore, I think, we probably must separate both cases in the draft.... Need to think more. It would be GREAT if we could combine them, as you suggested... 

> > This needs to come out much more clearly. Should this "hard coded"
> > behaviour be changeable under certain conditions? (Don't think so,
> > but...) The knee-jerk reaction would be to put this under 3.1, but I
> > think it's more important than that! It should be explained very
> > early, somewhere in 1), maybe in  1.2. Happy to write up some text if
> > the team wants me to (and if we agree ;-)
> >
> From a protocol perspective the pledge completes authentication as part of
> the TLS handshake and only after that is complete does it ‘request join’. So I
> called these distinct states. I don’t feel strongly about it though and am open
> to combining these states.

But it is a single TLS connection? (I'm not yet entirely clear on the latest protocol discussions)

I think: If we really have two separate TLS connections, then we can split; but if it's just different transactions within a single TLS connection, I would call it one state. 

> > - I think we need to bring out more strongly that the state machine needs
> to track peer and domain. Because, if there is a failure, the pledge should,
> depending on the failure of course, not try the same domain again, and
> probably not the same peer either. This isn't coming out today.
> > In fact, this is why I liked the "adjacency table" so much that I presented in
> Berlin (and before): Because there you see much clearer that, if enrolment
> fails with peer x, you may just move to the next one. As mentioned it's all
> there, but to a new reader this won't come out clearly, I'm afraid.
> 
> Yeah, I can see your point that this is buried in the text of 3.1.1 where it is
> implied that there is a list of "services returned during each query” and in
> failure the list processing "picks up where it left off” but thats pretty subtle.

Yes, I think we could be more explicit; discovery finds a set of nodes with different characteristics, and we need to explain how to navigate through this set. 

> > - We may want a "reason for rejection" if the domain rejects a device (for
> all negative cases). In some case, it could be a "wait a minute, I'm currently
> overloaded", in others "we don't like you in this domain", or "your enrolment
> mode (see first point) is not acceptable".
> > In "real life" this would allow some visual feedback at the install site, so that
> the engineer knows whether he should wait or can go.
> > [note: there may be security reasons to NOT give a reason for
> > rejection, need to think more about this]
> 
> I think here we need to provide information about what happened. This is
> why s5.4 exists to have the pledge send telemetry back to the network that
> attempted bootstrapping.
> 
> But note this is from the pledge to the domain. The device is assumed to be
> headless/zero-touch etc so I wasn’t thinking in terms of sending error
> messages to it. I’m open to doing so though.

Indeed. I think we can probably find security reasons why we don't want too much information back to the pledge, ideally just yes/no. 

However, I think there are three cases an installing person needs to distinguish: 
green: device is enrolled; you can go!
red: device was rejected; stick a big label on the device "rejected" and send to NOC. Try another device, or go home.  
yellow: there is a temporary issue; wait. 

And we should at least provide that level of information back to the pledge. 

> > - I didn't quite like "imprint" as a state either. To me, the next logical state
> was "validation". see attached ppt for more details. But bottom line, we
> need to reflect the 3 "paths" through the algorithm here again.
> 
> 
> > - And finally, I suggest we rename "being managed" to "enrolled".
> > Reason is: I'm also drawing up a complete state machine for an ANIMA
> > node, and there I think the main "transition points" between BRSKI and
> > ACP is when the device is "enrolled". Thus I suggest to call the final
> > state in BRSKI "Enrolled", and the first one in ACP the same.
> > (Besides, "being managed" doesn't sound right when we're talking a
> > fully autonomic device.)
> 
> I think there is a distinction between “obtaining an identity on the domain”
> and “what i do after I have an identity to be engaged with the domain”. So
> there are two states here. But yes, “being managed” could be “on the
> domain” or something.

Agree, but I think "what I do after I have an identity" is out of scope for this doc. (we have some informal section on this, 4.5, which is probably useful). 

> > In the attached ppt I made those few changes, and I marked with a red
> star, where I think we need more work before any last call, apart from what  I
> already mentioned:
> >

And that needs to be written somewhere in BRSKI, agreed? We need a section on how the proxy discovers a Registrar; Registrar selection, etc. Sigh... More work!

> > But, we'll need the same method also for the ACP draft: When both nodes
> have a certificate, they need to discover each other as well.
> > I've been haggling with Toerless about this :-)   I think we should take the
> mDNS insecure discovery into a separate, new draft.
> 

That wasn't my point; I wanted to say that we need to specify exactly which discovery methods are used in BRSKI and ACP.  

> > This is likely very short, BUT: I think it doesn't really belong in the BRSKI
> draft (specifically if we use BRSKI also for non-ANIMA environments), neither
> in the ACP draft (because we also need it in BRSKI). Having a separate draft
> would be very clean. However I understand (when pushed hard) we may not
> want to do this for admin reasons.
> > Alternatively, we specify the discovery in the ACP draft, and BRSKI refers to
> it. I like this less, but will not scream murder if others insist.
> 
> I think discovery of the proxy must be in this draft. I’m happy to move the
> proxy’s discovery of the registrar to another draft but I think its ok to
> recommend GRASP for that connection so I don’t see a problem with that.

I suggest we leave that in the BRSKI draft. 

Thanks for your quick response! 
Michael

> - max
> 
> >
> > So much for now. Still on the full review, but this is pretty high level, and
> pretty fundamental. Happy to help with text and/or ASCII art if we decide to
> take on some of these points.
> >
> > Michael
> >
> >
> > <brski state
> >
> machine.pptx>_______________________________________________

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 18 Oct 2016 08:03:46 +0000

> Sent: 18 October 2016 01:18
> To: Max Pritikin (pritikin) <[email-masked]>; Michael Behringer
> (mbehring) <[email-masked]>
> Subject: peer and domain [was BRSKI State Machine]
> 
> 
> 
> In that case it seems to me that the discovery process (whether it's mDNS or
> GRASP) will discover all available proxies regardless of domain. And then try
> them in some order of preference TBD.

"peer" is an entry in the adjacency table. Yes, there may be several on an interface, of several different domains. The adjacency table discussion tries to capture that. 
 
> Also, all of this needs to work in the absence of an ACP and therefore of the
> ACP's adjacency table. That applies to GRASP too, because in order to
> perform its various link-local actions, it needs to know which interfaces it has
> and which link-local addresses it has. And it learns of its link-local neighbors as
> a result of discovery. So while I fully appreciate the value of the adjacency
> table, we need to be functional without it.

Now we're getting into a muddle with ANIMA vs non-ANIMA modes. (And you're right - this is important to sort out). Let's see whether we can sort that. 

Up front: This is the ANIMA WG, and we're primarily defining the behaviour of an ANIMA node. This is, IMO:

- There is an adjacency table, that observes what nodes are seen on each ANIMA-capable interface. 
- This table is fed by discovery (primarily). 
- Depending on the state of the node, and the state of an adjacent node, different things will happen. 
  (see my presentation on the reference model, last IETF - all described there)

For ANIMA, we need to settle on MUST discovery methods. 
In ANIMA, we will ALWAYS build an ACP to other nodes of the same domain. 

The adjacency table links BRSKI and ACP automatically: Once I discover a node which is in the same domain, I attempt to set up an ACP connection with that node. 

Outside ANIMA, GRASP can be used in many other ways; BRSKI can be used to derive LDevIDs and nothing else. 

Do we agree? 
Michael

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 18 Oct 2016 14:37:14 +0000

> On Oct 17, 2016, at 5:18 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> 
> 

Agreed. From the perspective of a Pledge new device anything discovered is a “proxy” or perhaps a registrar but it doesn’t yet know the domain(s). 
> of the adjacency table, we need to be functional without it.

Michael things of discovered proxies as adjacencies for the table. I think of them as a “list of discovered proxies”. The concepts are similar and Michael is correct that the current sentence could be clearer.

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 18 Oct 2016 14:52:11 +0000

RE #1 (“trust on first use” or “zombie duckling”)

This is not supported by the current text but is not specifically excluded. I propose next text within section1 that indicates this. 
	Support for a ‘trust on first use’ model is not provided by this protocol specification. Devices that claim compliance 
        to this specification MAY support Trust on first use can exist on physical interfaces but MUST NOT support trust-on-first-use 
        on network interfaces.

I have nothing inherently against people building zombie duckling devices. Zombies are cool! I simply don’t want them to also claim support for a secure protocol as well. 

- max

> On Oct 18, 2016, at 1:51 AM, Michael Behringer (mbehring) <[email-masked]> wrote:
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Oct 2016 08:46:20 +1300

> "peer" is an entry in the adjacency table. Yes, there may be several on an interface, of several different domains. The adjacency table discussion tries to capture that. 

Fair enough. But anyway my comment still applies: a node that is joining the ACP,
or simply updating its ACP adjacencies, will discover all available neighbors...

> The adjacency table links BRSKI and ACP automatically: Once I discover a node which is in the same domain, I attempt to set up an ACP connection with that node. 

Sure. And I think I can model that with GRASP - it simply needs an objective
that includes the domain and node credentials, right?

> Outside ANIMA, GRASP can be used in many other ways; BRSKI can be used to derive LDevIDs and nothing else. 

I think so. But I won't know so until I see what the ACP's API looks like.
Remember that GRASP needs to create unicast and multicast sockets, so in an
ACP regime those sockets need to be provided by the ACP.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 19 Oct 2016 07:21:40 +0000

> > In that case it seems to me that the discovery process (whether it's
> > mDNS or GRASP) will discover all available proxies regardless of
> > domain. And then try them in some order of preference TBD.
> 
> Agreed. From the perspective of a Pledge new device anything discovered is
> a “proxy” or perhaps a registrar but it doesn’t yet know the domain(s).

Mostly agree; two small edits: I would say " From the perspective of a Pledge anything discovered is a *potential* “proxy”."

I would not mention the registrar, since we decided that if a device happens to be a registrar, it should still behave like a proxy, to keep the behaviour of the pledge as simple as possible. 

(I'm sure we agree - these are just editorial comments)

> > of the ACP's adjacency table. That applies to GRASP too, because in
> > order to perform its various link-local actions, it needs to know
> > which interfaces it has and which link-local addresses it has. And it
> > learns of its link-local neighbors as a result of discovery. So while
> > I fully appreciate the value of the adjacency table, we need to be functional
> without it.
> 
> Michael things of discovered proxies as adjacencies for the table. I think of
> them as a “list of discovered proxies”. The concepts are similar and Michael is
> correct that the current sentence could be clearer.

Seen from BRSKI, you are right. 

My main comment really is: Adjacency discovery, as well as the adjacency table, is really independent of both BRSKI and ACP. It is a feature of an *autonomic node*. When an autonomic node is in factory default, it will use the adjacency table to invoke bootstrap; when it is in a domain, it will use the same table to create an ACP connection. So the adjacency discovery and the table are really separate from BRSKI and ACP. 

Because of this, I've said for a while the really "correct" thing to do would be to make a separate (short) draft for autonomic adjacency discovery, and the adjacency table. This would be a really nice place to describe the general behaviour of an autonomic node. 
 
Right now we really specify the same thing in both BRSKI and ACP drafts. First of all, I think we should be VERY clear that we don't want *two* mechanisms to discover a proxy or an ACP neighbour. We want a single protocol to do this. (I think we agree up to here). 

The chairs have been pushing hard against another draft, for purely practical reasons, and I understand that, and can live with it. 

But let's be clear that this should really be the same protocol, it should be specified in one place only, and the other refers to that. (Again, I think we agree on that). 

Here's what's going to happen in phase 2 of ANIMA: 
- We'll want Intent to say things like "trust autonomic devices in domain x for the sole purpose of auto-negotiating BGP security". 
- or "if a node in sp.net sees one in customer.sp.net, it should create a 'unidirectional' ACP"
- Therefore, a node now needs to scan its adjacency table, see where there are nodes of domain x. 
- for such nodes, we'll establish another form of security association, we will NOT include them in the general ACP. 
- so there will be another way to handle nodes in the table that we've ignored so far. 
- This will result in another draft. 
- Now, without the adjacency discovery draft, we need now to point to another "use case" draft, e.g., BRSKI for the details of adjacency discovery, and what to do in which case. 

To me, we are turning cause and action the wrong way round. 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Oct 2016 08:42:48 +1300

Picking out a couple points:

> Right now we really specify the same thing in both BRSKI and ACP drafts.

It's a bit worse, because in practice GRASP has to do a lot of the same
stuff. I won't trouble you with details, but the first sections of GRASP
initialisation carry these comments:

# Initialise global variables
# Is there an ACP?
# What's my address?
# What interfaces do I have?
# Create sockets to send LL multicasts
# Initialise TCP sockets to receive unicast Discovery responses
# Start relay if needed

So, although it doesn't deal with adjacencies as such, if it could
simply grap the adjacency table from the ACP, all of the above would
be much more straightforward. However, that may have things backwards.
If the first thing a GRASP node did after initialisation was something
like flood(objective("AN_ACP")) and then listen for incoming floods from
neighbors, it could quickly learn its potential ACP adjacencies.

So, perhaps ACP formation is a special case ASA that runs always, in insecure
link-local mode, to maintain adjacencies and support the creation of
secure ACP tunnels.

I could write demo code for the adjacency learning, but I'd need some help
on the domain ID.

> make a separate (short) draft for autonomic adjacency discovery, and the adjacency table.

If it's needed we can write it up. Then either embed it arbitrarily in one
of the other documents, or discuss it with the WG.

Regards
   Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 19 Oct 2016 20:05:31 +0000

> On Oct 19, 2016, at 1:42 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> stuff.

Isn’t this a result of not clearly defining the dependencies? If GRASP clearly depended on the ACP then some of this redundancy would go away? 

For example, if GRASP s3.3.1 required the ACP instead of only indicating that the ACP “SHOULD” exist then a dependence on the adjacency table from ACP-03 s5.1.2 would be clear. Ref:
	https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.3.1
	https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-03#section-5.1.2
	and the core adjacency table discussion in:
	https://tools.ietf.org/html/draft-ietf-anima-reference-model-02#section-5

The BRSKI doc can’t reference ACP so instead I’ll update the list of adjacencies discussion to reference only the anima-reference-model (informational). 

- max

> I won't trouble you with details, but the first sections of GRASP

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Oct 2016 13:03:40 +1300

> Isn’t this a result of not clearly defining the dependencies? If GRASP clearly depended on the ACP then some of this redundancy would go away? 

That's true, but the requirements that we're working off include being able to
operate with no ACP. If we change that, we lock GRASP in. I don't think that's
desirable.

> The BRSKI doc can’t reference ACP so instead I’ll update the list of adjacencies discussion to reference only the anima-reference-model (informational).

I think that's wise. We should probably add a similar reference to the adjacency
table in the GRASP spec. I've just put some text in my working copy. Basically:

if ACP is up:
    get interface & address info from the adjacency table
else:
    dig it out from the operating system yourself

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Oct 2016 11:23:13 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:
    >> In "real life" this would allow some visual feedback at the install
    >> site, so that the engineer knows whether he should wait or can go.

    > I think here we need to provide information about what happened. This
    > is why s5.4 exists to have the pledge send telemetry back to the
    > network that attempted bootstrapping.

This is a hard problem I think, ; there is potential for a lot of chaff in
the log if we do it wrong.

    > But note this is from the pledge to the domain. The device is assumed
    > to be headless/zero-touch etc so I wasn’t thinking in terms of sending
    > error messages to it. I’m open to doing so though.

I agree that this is important...

    >> names, and other details. In my head we're using mDNS here, and I
    >> *think* we agreed on that?

    > discovered using GRASP for ACP devices.

https://datatracker.ietf.org/doc/draft-richardson-anima-6join-discovery

Posted yesterday, needs work. Needs to be merged into bootstrap document, I think.

    MB> But, we'll need the same method also for the ACP draft: When both
    MB> nodes have a certificate, they need to discover each other as well.
    MB> I've been haggling with Toerless about this :-)   I think we should
    MB> take the mDNS insecure discovery into a separate, new draft.

    > can’t establish a secure discovery yet.

mDNS is just fine to find *a* proxy for a pledge that doesn't know anything else.
(And couldn't verify the proxy anyway).

I'm still unclear how the GRASP multicast discovery process is going to work
(the details) such that it leads to an IKEv2 connection.  *All* we need to
form the ACP links is a multicast that says, "I speak ACP", and as I
suggested before, this could be an multicast IKEv2 PARENT_I1 as much as
anything else.   Or we use the GRASP discovery multicast port, and the
response is not a TCP connection that says, "I'm here", as much as just an
IKEv2 packet instead.

so I disagree with MB above: it's not the same protocol requirements at all.

    > I think discovery of the proxy must be in this draft. I’m happy to move
    > the proxy’s discovery of the registrar to another draft but I think its
    > ok to recommend GRASP for that connection so I don’t see a problem with
    > that.

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Oct 2016 11:26:33 -0400

> - This table is fed by discovery (primarily).

So, should an ACP capable node simply periodically multicast a cleartext
M_NOOP on the underlying link?
That would work and provide all the information the adjacency table needs.

All other GRASP messages (including discovery) would be occuring inside the
ACP, so there wouldn't be anything visible on the underlying link to drive
the adjacency table.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Oct 2016 11:35:35 -0400

> I could write demo code for the adjacency learning, but I'd need some help

I can live with this solution, but I'm not sure that MB is thinking about it
in these terms.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Oct 2016 11:34:10 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > Right now we really specify the same thing in both BRSKI and ACP
    > drafts. First of all, I think we should be VERY clear that we don't
    > want *two* mechanisms to discover a proxy or an ACP neighbour. We want
    > a single protocol to do this. (I think we agree up to here).

I don't think I agree.

I'm also pretty unclear how to feed the ACP adjacency table easily from the
entire GRASP discovery process, including the TCP based reply mechanism, and
doing this on the insecured underlying network...

Perhaps if we had a new M_ANNOUNCE or something that was suitable for
multicasting, and which elicited no reply, that would be fine. It duplicates
the part of mDNS that we found useful.

Essentially it's just [M_NOOP, ["announce", stuff]]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2016 08:49:21 +1300

in line...

> (And couldn't verify the proxy anyway).

s/mDNS/GRASP/ and both of those sentences remain true: pre-ACP, the security
properties of GRASP are pretty much the same as mDNS.

> response is not a TCP connection that says, "I'm here", as much as just an

I think I would recommend using GRASP flooding; if you want to call the
objective "I speak ACP" that would be fine ;-). But afaics it's functionally
equivalent to just using IKE, *except* that we'd have the flexibility to
announce the method, as in ["I speak ACP",2,1,["IKEv2"]].

>     > ok to recommend GRASP for that connection so I don’t see a problem with

And what's wrong with stating that a proxy MUST support being discovered
by mDNS and GRASP, and that a pledge MUST support mDNS or GRASP?

I actually though we agreed on that in Berlin.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2016 08:56:05 +1300

> Essentially it's just [M_NOOP, ["announce", stuff]]

It can be [M_FLOOD,,,,["I talk ACP",,,,,stuff]]

GRASP seems to be pretty versatile, even without new message formats.

   Brian