Subject: [Anima] ANIMA state machines, take two

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 10 Nov 2016 16:04:27 +0000

I had already sent out an early version of the state machines before, here an update. 

To the high level state machine, I added a state "Proxy mode". A node is in that state when the ACP is up AND it can see a registrar. Other than that, I think the high level diagram should be ok. Looking for feedback. 

The state machine for the BRSKI pledge (it's a detail on the ANIMA state machine) still has a lot of open questions. Most are under discussion. I tried to illustrate where we have open points. 

I now tried also a state machine for the ACP. I'd appreciate some feedback on it. 

To me, the big open things are: 
- nail down discovery protocol and packet formats for both discoveries (for bootstrap and ACP). 
- decide which (if any) feedback we want to give to the pledge. 

But, I think these diagrams show nicely how all the drafts fit together, which was the purpose of this exercise.

Feedback? See you in Seoul! (Will be there from Sunday evening)
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Nov 2016 08:27:57 +1300

Michael,

I like this. I have a few comments on some of your open questions:

> Discovery:	
>    mDNS or GRASP?

I feel very strongly that we need the ANI to be as self-contained as
possible. Therefore, it must be possible for the ANI to create itself
without depending on mDNS. Therefore, we must use GRASP discovery
(or flooding, if we prefer an announcement method) for AN nodes.

> one discovery method for BRSKI and ACP, or several?

Non-ANI nodes can also use BRSKI. So to say this one more time, since I
won't be in Seoul: BRSKI proxies MUST be discoverable by both mDNS and GRASP.

(One open question in my mind is this: does the pledge know or care
whether it is dealing with a proxy or directly with the registrar, if
the registrar happens to be on the local link? That does affect some
details, at least in the GRASP case.)

> multicast domain info?

> packet formats

For the discovery methods, that is already settled by mDNS and GRASP,
isn't it? For BRSKI itself and ACP formation, the formats belong in
the BRSKI and ACP drafts.

Regards
   Brian

On 11/11/2016 05:04, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 06:17:23 +0900

> To the high level state machine, I added a state "Proxy mode". A node
    > is in that state when the ACP is up AND it can see a registrar. Other
    > than that, I think the high level diagram should be ok. Looking for
    > feedback.

I disagree with this state or machine.
The proxy process is, as you described, dependant upon having reached the In
ACP mode, and having discovered a Registrar.  That's true.

Assuming IKEv2 (whether keying IPsec, or keying MACSEC [%])

There is some RPL state machine inside the In ACP state as well, but
I'm not 

But, I wouldn't describe it as a seperate state, rather it's an attribute
of having reached In ACP mode.  I would expect the ACP process, once it has 
been informed by the RPL daemon that it has found a ground RPL DODAG to join,
that it would spawn off the Join Assistant process.

The Join Assistant would then open a TCP socket to receive the GRASP reply
(binding the socket to the ACP ULA address), and then do a GRASP M_DISCOVERY.
Once it gets a response from a Registrar, it would begin listening for New
Node discovery messages and relaying.  This would be a seperate state
machine.  Would you like this in the bootstrapping document?

    > The state machine for the BRSKI pledge (it's a detail on the ANIMA
    > state machine) still has a lot of open questions. Most are under
    > discussion. I tried to illustrate where we have open points.

You have listed:

Discovery:	
  mDNS or GRASP? 
  one discovery method for BRSKI and ACP, or several? 
  multicast domain info? 
  packet formats
BRSKI:
  Feedback to the pledge? (specifically: Reason for rejection / retry?)

Let me be more specific, because I think these are not open questions.

Discovery of AN peer:
    - GRASP M_FLOOD  (MTI)

Discovery of Join Assistant by Pledge:
    - GRASP M_FLOOD  (MUST for JA, SHOULD for Pledge)
    - mDNS (SHOULD for JA, MAY for Pledge)

The "multicast domain info" question is vague to me, but if you mean the
multicast scope, it's LL, scope=2.  (scope=1 being host)

Packet formats are determined by GRASP and mDNS.

The feedback to the pledge about rejection would occur inside of EST,
and so is about RFC7030, right?

[%] - Linux now has a MACSEC implementation I noticed. 
    If supporting MACSEC is interesting to many, then we need a KMP for it,
    and we need to negotiate it's use via IKEv2.
    I suggest that a document doing this would not be very long or difficult
    to pass through the IPsec WG.
    If supporting MACSEC is not a priority now, then as long as we negotiate
    the ACP using IKEv2, then we can add it later on rather easily.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2016 12:44:01 +0900

{pushing send on an email in process for some days}

    >> Discovery: mDNS or GRASP?

    > without depending on mDNS. Therefore, we must use GRASP discovery (or
    > flooding, if we prefer an announcement method) for AN nodes.

I agree that enrolled AN nodes MUST use GRASP for discovery, and I think that
M_FLOOD is the way to create the neighbour table for that.

    > won't be in Seoul: BRSKI proxies MUST be discoverable by both mDNS and

I am warming to use of M_FLOOD for this, whereby the Join Assistant announces
itself.

    > isn't it? For BRSKI itself and ACP formation, the formats belong in the
    > BRSKI and ACP drafts.

Agreed, I don't think that there are any open questions here.

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