Re: [Anima-bootstrap] BRSKI State Machine

Brian E Carpenter <> Thu, 20 October 2016 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90AC11294A9 for <>; Thu, 20 Oct 2016 12:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8EoFmmLEKQRE for <>; Thu, 20 Oct 2016 12:49:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA8BE12966C for <>; Thu, 20 Oct 2016 12:49:17 -0700 (PDT)
Received: by with SMTP id e6so42407581pfk.3 for <>; Thu, 20 Oct 2016 12:49:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2mV69LaqPflnCqn9yv1Y9E8nHhzB7SyoZAQIDUcAkt4=; b=CkKLeMFLOtEaAqplm0pkemIpdiXMNiLBy70LVEvzyWbCAx1anoE/p3j5y4xhfxiF6u 2y1HWTzjTlSSUo/GyLXRjXekenCtfJTixzg0IFP1k99e2znrlJNYl7Ot3O1UKEVfYqba n639wu2IBhWViUQMo21BkUsBpmhsEFJFh3+P0pm0OzuSsePezM5Ik9kAUnNJlIIMb+Yc VUACxZYbMN257Bj5vurYKgvT3E1zrtTwPYyh6dIev0ndO7WSxZ4YH2x2YCxYvUjsxBhA hCQ8C5u7iM1KctGpYhX4i9rHZuMiwPh4VOr6ivzjH+KYhiMQ2UE307hSMp2tfSlejj/e On+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=2mV69LaqPflnCqn9yv1Y9E8nHhzB7SyoZAQIDUcAkt4=; b=UxK50Hyb2vK9gt3GGcnMTW3F/V3kdljq7ZzkndRJGNazNdKu5hosANfSeYYkqlhnkV vtNUeFNSc1KuIXXBg5vV89L7Q8eCVs0DJBZfW9bIdki5AnRhC5hK+lTcnYHs5cDv6+3Y g6nQzdWBgatnC+NhgwI6RbXvkTkGnGuNRomSGqBis1Jje4mOk1x9b2awkmx1WvftMi5p rbm8FtInjC2P9b5s59Oit+FfYuWvmiYwyKJ7G+/yGRXrJsaK+86jdwJXaQ6YuMBkoiv9 56EEEaY6MUnzEfvXRZyYRTDvFxdNUU33TnLrYQGecuZtEoG7OcystnDOUs3TfExMC573 3sYw==
X-Gm-Message-State: AA6/9RnQSJQ9nNwL+sdieoqgT2EkObZY7P95xZQa9yFR10zc/EM6qPuAOppKvTAfaG79iw==
X-Received: by with SMTP id r87mr4341121pfk.108.1476992957295; Thu, 20 Oct 2016 12:49:17 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id p3sm13123781pfg.48.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Oct 2016 12:49:16 -0700 (PDT)
To: Michael Richardson <>, "Max Pritikin (pritikin)" <>
References: <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 21 Oct 2016 08:49:21 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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 19:49:19 -0000

in line...

On 21/10/2016 04:23, Michael Richardson wrote:
> 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).

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

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

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

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

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.