Re: [Anima-bootstrap] BRSKI State Machine

Michael Richardson <> Thu, 20 October 2016 15:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19ED01297B8 for <>; Thu, 20 Oct 2016 08:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sN8A0NBZr_NK for <>; Thu, 20 Oct 2016 08:23:14 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ADE5129657 for <>; Thu, 20 Oct 2016 08:23:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A84FF2054E; Thu, 20 Oct 2016 11:37:55 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 2BB19639BA; Thu, 20 Oct 2016 11:23:13 -0400 (EDT)
From: Michael Richardson <>
To: "Max Pritikin (pritikin)" <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 20 Oct 2016 11:23:13 -0400
Message-ID: <>
Archived-At: <>
Cc: "" <>, "Michael Behringer (mbehring)" <>
Subject: Re: [Anima-bootstrap] BRSKI State Machine
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Oct 2016 15:23:16 -0000

Max Pritikin (pritikin) <> 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.
    >> [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.

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...

    >> - 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.

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.

    > I don’t follow. mDNS simply *is* insecure. This is important since we
    > 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 <>, Sandelman Software Works
 -= IPv6 IoT consulting =-