Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
"Fries, Steffen" <steffen.fries@siemens.com> Mon, 31 August 2020 14:41 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 C596F3A1494
for <anima@ietfa.amsl.com>; Mon, 31 Aug 2020 07:41:17 -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 YjF87Nyk1Fc9 for <anima@ietfa.amsl.com>;
Mon, 31 Aug 2020 07:41:16 -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 1C6533A1492
for <anima@ietf.org>; Mon, 31 Aug 2020 07:41:15 -0700 (PDT)
Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78])
by gw-eagle2.siemens.com (Postfix) with ESMTPS id BAF70468019;
Mon, 31 Aug 2020 16:41:13 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net (sop-solman.siemens.com
[139.25.226.107])
by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id A2B27163A0169;
Mon, 31 Aug 2020 16:41:12 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) by
DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2044.4; Mon, 31 Aug 2020 16:41:11 +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;
Mon, 31 Aug 2020 16:41:11 +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//zLWwP/8IcqA//OyUCA=
Content-Class:
Date: Mon, 31 Aug 2020 14:41:11 +0000
Message-ID: <523e10f22ec84f83ad8c0f0b9bc85c4a@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>
<31381.1598639539@localhost>
In-Reply-To: <31381.1598639539@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-31T14:41:10Z;
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=93669f3a-0fdd-4c73-a901-2a2cf8091057;
MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [144.145.220.65]
x-tm-snts-smtp: 019F1BF88280A7308853DD009341419E7CBA96B5B122216702A1A245ACA3864B2000: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/4uXwUd9brODlKERSz84VxYRmzx8>
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: Mon, 31 Aug 2020 14:41:18 -0000
Hi Michael, > -----Original Message----- > From: Michael Richardson <mcr+ietf@sandelman.ca> > Sent: Freitag, 28. August 2020 20:32 > > 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. Yes, this keeps the pledge simple, but would require the registrar to implement the other options mandatorily. > > 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. This would also be an option for a discovery, but I have to dig deeper into GRASP. > > >> 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 realize more an more that a pure "request-object" without considering the transport is probably too abstract. Implementing requires also the transport. > I thought that was what we were doing.. I have many ideas about this. Yes, voucher-request and also certification-request would be collected by the pledge-agent. Good to hear you have ideas here, as we need to define the approach more precisely. > > > 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? The pledge essentially must be able to listen for the request. In industrial environments the embedded device is most often in a server role waiting for requests. This would have to be leveraged also for the PUSH interaction. > > > 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. That sounds great. Your support is greatly appreciated here.. > > > 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. This was one of the point I concluded form the last meeting. The trust assumptions about the pledge and pledge-agent interaction is one of the points to be discussed further. > > 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. Which may bring it closer to the constraint voucher than BRSKI. I was looking for the latter, hence HTTP as proposal. But this is open for discussion. Best regards Steffen > > -- > Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > >
- [Anima] Handling of endpoint path names (from BRS… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Eliot Lear
- Re: [Anima] Handling of endpoint path names (from… Toerless Eckert
- Re: [Anima] Handling of endpoint path names (from… Toerless Eckert
- Re: [Anima] Handling of endpoint path names (from… Brockhaus, Hendrik
- Re: [Anima] Handling of endpoint path names (from… Brian E Carpenter
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- [Anima] possible last minute changes to anima-boo… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] possible last minute changes to anima… Mark Nottingham
- Re: [Anima] possible last minute changes to anima… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Werner, Thomas
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Fries, Steffen
- Re: [Anima] Handling of endpoint path names (from… Michael Richardson
- Re: [Anima] Handling of endpoint path names (from… Brian E Carpenter
- Re: [Anima] Handling of endpoint path names (from… Esko Dijk
- [Anima] constrained handling of endpoint path nam… Michael Richardson
- Re: [Anima] constrained handling of endpoint path… Esko Dijk
- Re: [Anima] constrained handling of endpoint path… Michael Richardson