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

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 27 August 2020 12:56 UTC

Return-Path: <steffen.fries@siemens.com>
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 D37733A07E5 for <anima@ietfa.amsl.com>; Thu, 27 Aug 2020 05:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 OYB2fWeXmYVD for <anima@ietfa.amsl.com>; Thu, 27 Aug 2020 05:56:40 -0700 (PDT)
Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C133A07CE for <anima@ietf.org>; Thu, 27 Aug 2020 05:56:40 -0700 (PDT)
Received: from mail2.dc4ca.siemens.de (mail2.dc4ca.siemens.de [139.25.224.94]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id D53384681AD; Thu, 27 Aug 2020 14:56:38 +0200 (CEST)
Received: from DEMCHDC8A2A.ad011.siemens.net (demchdc8a2a.ad011.siemens.net [139.25.226.108]) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id 80CEF15617AB1; Thu, 27 Aug 2020 14:56:35 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) by DEMCHDC8A2A.ad011.siemens.net (139.25.226.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 27 Aug 2020 14:56:35 +0200
Received: from DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) by DEMCHDC8A1A.ad011.siemens.net ([139.25.226.107]) with mapi id 15.01.2044.004; Thu, 27 Aug 2020 14:56:35 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
Thread-Index: AdZmfbkJ/iBKc9n1QAWzDvrnlpnz3///+0AAgAeRb4D//879sIACHpmA//7t5iCAFspqgP//3RWAAXKuHAD//zLWwA==
Content-Class:
Date: Thu, 27 Aug 2020 12:56:35 +0000
Message-ID: <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>
In-Reply-To: <11109.1598470952@localhost>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-08-27T12:56:34Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=4f01ec2b-52b6-4aa0-9d17-09c56726102c; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [139.23.75.59]
x-tm-snts-smtp: 11A33D7F90D8DE3862DDF8012EC1256D1193D5E370B5CE1330BC42F0982AA0AB2000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Vc99q_sJMF-HqH4HMJGBaDJVBMw>
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: Thu, 27 Aug 2020 12:56:42 -0000

> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Mittwoch, 26. August 2020 21:43
> 
> Fries, Steffen <steffen.fries@siemens.com> wrote:
>     >> Can you explain to me why the discovery via /.well-known/brski is
>     >> useful?  This is on the *REGISTRAR*.
> 
>     > 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.

 
>     >> In reading BRSKI-AE, I seem to be missing any place where the PUSH
>     >> mechanism is described.  In a PUSH use case, what protocol would the
>     >> pledge expose to the pledge-agent and/or commissioner?
> 
>     > This is currently left outside in terms of the protocol. The intention
>     > was to only specify the necessary (signature wrapped) data objects to
> 
> 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. This was also a reason for the discovery option. 
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 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 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?

Best regards
Steffen

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