[Anima-bootstrap] BRSKI State Machine

["Michael Behringer (mbehring)" <[e-mail]>]

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