[Anima-bootstrap] BRSKI State Machine

"Michael Behringer (mbehring)" <mbehring@cisco.com> Fri, 14 October 2016 14:42 UTC

Return-Path: <mbehring@cisco.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 530301297AE for <anima-bootstrap@ietfa.amsl.com>; Fri, 14 Oct 2016 07:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.517
X-Spam-Status: No, score=-17.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kKpUDWs6qOkw for <anima-bootstrap@ietfa.amsl.com>; Fri, 14 Oct 2016 07:42:16 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8831297A9 for <anima-bootstrap@ietf.org>; Fri, 14 Oct 2016 07:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51757; q=dns/txt; s=iport; t=1476456136; x=1477665736; h=from:to:subject:date:message-id:mime-version; bh=j8ESo8DylWLvrn62Sr1KAl1gTwWYHY/CqQM9O2UGvKk=; b=aNei7Byp5Ae1NkV7YcIBz2dtb8+8xhikiu1rvb+JbgS648qFkk+W0dBE 3gjIz2mjaIKAi9QO+HxrLOnJn5lJHIThPTmZ/nJbLG6jzezwsZKTAnP9a 5GCcNSfoctOMKBHIFTJ+h7fj2HGtYTDHmewCgO+nu2cx4Ge4N/MwOda2i g=;
X-Files: brski state machine.pptx : 33735
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,493,1473120000"; d="xml'?pptx'72,48?scan'72,48,208,145,72,48?jpeg'72,48,208,145,72,48,145?rels'72,48,208,145,72,48,145"; a="157966496"
Received: from alln-core-9.cisco.com ([]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2016 14:42:15 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com []) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u9EEgElj004959 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <anima-bootstrap@ietf.org>; Fri, 14 Oct 2016 14:42:14 GMT
Received: from xch-rcd-006.cisco.com ( by XCH-ALN-007.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Oct 2016 09:42:14 -0500
Received: from xch-rcd-006.cisco.com ([]) by XCH-RCD-006.cisco.com ([]) with mapi id 15.00.1210.000; Fri, 14 Oct 2016 09:42:14 -0500
From: "Michael Behringer (mbehring)" <mbehring@cisco.com>
To: "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>
Thread-Topic: BRSKI State Machine
Thread-Index: AdImIxW8sCw9I7ieQW++wlMDDTidqA==
Date: Fri, 14 Oct 2016 14:42:14 +0000
Message-ID: <c41c231f3906477f97f1641617de025e@XCH-RCD-006.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_002_c41c231f3906477f97f1641617de025eXCHRCD006ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/NuRM8OjtrU7YzQNrRSTm3qiUT3c>
Subject: [Anima-bootstrap] BRSKI State Machine
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 14:42:18 -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.