Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 28 August 2020 18:32 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024933A012A for <anima@ietfa.amsl.com>; Fri, 28 Aug 2020 11:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1fZvqAf7vgr for <anima@ietfa.amsl.com>; Fri, 28 Aug 2020 11:32:22 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8BA3A0112 for <anima@ietf.org>; Fri, 28 Aug 2020 11:32:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 15286389D7; Fri, 28 Aug 2020 14:11:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qLCJ__Q_MD7e; Fri, 28 Aug 2020 14:11:20 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C994A389D5; Fri, 28 Aug 2020 14:11:19 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BE3FFB3; Fri, 28 Aug 2020 14:32:19 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Fries\, Steffen" <steffen.fries@siemens.com>, "anima\@ietf.org" <anima@ietf.org>
In-Reply-To: <6563c1fbc9624eb687df3ae51b19ba76@siemens.com>
References: <3f2d1790efb44ac39405a23dc592dd89@siemens.com> <20200730161142.GB62130@faui48f.informatik.uni-erlangen.de> <12431.1596541563@dooku> <2c4323c817134845ae7c36b41fd239c1@siemens.com> <11029.1596647559@localhost> <eee14f13f5cf4183bf69e999c5fcea04@siemens.com> <6058.1597841627@localhost> <f3981ca4bde844dbb27213ae96185967@siemens.com> <11109.1598470952@localhost> <6563c1fbc9624eb687df3ae51b19ba76@siemens.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512; protocol="application/pgp-signature"
Date: Fri, 28 Aug 2020 14:32:19 -0400
Message-ID: <31381.1598639539@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/viyNZ_Nd7j6JMRBfkiyw-qQ-q98>
Subject: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2020 18:32:24 -0000

Fries, Steffen <steffen.fries@siemens.com> wrote:
    >> > The intention was to let the pledge or the pledge-agent know in advance
    >> > what enrollment options are available at the registrar side allowing
    >> > the pledge to fail fast if it does not have a matching enrollment
    >> > protocol.
    >>
    >> I understand this need, but it seems that we are making the pledge more
    >> complex in order to keep the registrar simpler.  That makes no sense to me:
    >> the pledge should be minimal, while the registrar can remain complex.

    > Maybe I phrased it wrong. The intention is not to make the pledge more
    > complex. The goal should be to keep the pledge simple and enhance the
    > registrar to handle also other situations like unavailability of
    > certain connections. The registrar should be the more capable
    > component. The discovery was intended in situations, in which the
    > registrar supports multipole options, but not all may be mandatory
    > supported. In this case the discovery would help. Otherwise the pledge
    > may do trial and error.

While I appreciate the idea of having the pledge fail faster, and go onto to
the next possible registrar, I think that the pledge should support one and
only one mechanism, and it's up to the registrars to keep up.

If we are doing proper ACP ANIMA, then we can include the enrollment options
for the Registrar into the GRASP DULL announcement, and this can inform the
pledge's decision as to which Registrar to pick.

    >> I'd really like to have the PUSH part in scope.
    >> I thought that it was just not done yet, but it seems to me that without the
    >> PUSH part, that the protocol isn't async at all.  It is just
    >> BRSKI-CMP.

    > Async was meant that connectivity to certain components is not
    > available at the time of the onboarding. For use case 1 it would be the
    > issuing PKI and in use case 2 the registrar. To handle this signature
    > wrapped objects were introduced. One way of addressing this during
    > enrollment is using protocols supporting signature wrapped objects like
    > CMP or EST with fullcmc as outlined. The goal is to be protocol
    > agnostic.

I don't yet understand how the voucher-request is done in async BRSKI.
I thought that was what we were doing.. I have many ideas about this.

    > This was also a reason for the discovery option.

I don't think it helps.

    > Regarding PUSH. As outlined in BRSKI-AE section 5.2.4 the pledge would
    > be queried by the pledge-agent for certain objects. It was intended to

But, how is it queried?

    > have it in the current document. The current description assumes that
    > it would be sufficient to define just the signature wrapped objects to
    > be exchanged between the pledge-agent and the pledge and not the
    > transport of these objects to be open regarding the underlying
    > media. This would allow to use the functionality of the domain

okay, so I'm very interested in helping define this well enough to be used.

    > registrar via the pledge-agent, even of the pledge utilizes a different
    > network stack. But maybe this is to far fetched and it is easier to
    > concentrate on the currently assumed pledge capabilities (in BRSKI) to
    > do HTTP as a starting point. I think that this needs further
    > discussion. Do you have a concrete use case in mind, which should be
    > addressed?

Well, I thought that the furnace in the basement where there is no
connectivity was a really good use case.
The furnace installer has a smartphone or dedicated comissioning device.

As for HTTP: I would tend to suggest that we should use CoAP.
This works over WIFI as well as other technologies, and convergence here
would be good.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-