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

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 20 August 2020 06:38 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 97EC43A087F for <anima@ietfa.amsl.com>; Wed, 19 Aug 2020 23:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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] 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 5yl_u__GFtqw for <anima@ietfa.amsl.com>; Wed, 19 Aug 2020 23:38:48 -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 36B443A046E for <anima@ietf.org>; Wed, 19 Aug 2020 23:38:47 -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 51D1346802F; Thu, 20 Aug 2020 08:38:46 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net (sop-solman.siemens.com [139.25.226.107]) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id 6AE721549E4A2; Thu, 20 Aug 2020 08:38:45 +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; Thu, 20 Aug 2020 08:38:44 +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, 20 Aug 2020 08:38:44 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "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//3RWA//6XhiA=
Date: Thu, 20 Aug 2020 06:38:44 +0000
Message-ID: <d1b2c1592b244c8b9cc005a6a44e4a27@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>
In-Reply-To: <f3981ca4bde844dbb27213ae96185967@siemens.com>
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-19T13:29:02Z; 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=255bcb19-b086-4eec-9a8b-cedfb332d40b; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [144.145.220.66]
x-tm-snts-smtp: B870948933F3E06FCEDADF538884B43BEF164BD19921DEB21144509017BFB1B72000: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/ulhqTpfqWkeo08bRp1mtf6buyxU>
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, 20 Aug 2020 06:38:50 -0000

Hi Michael,
> > As far as I can tell, in the PULL case, when CMP (or another
> > mechanism) will be used, there is still a voucher exchange first.  The
> > Registrar can express it's preference in the (parboiled) voucher-request
> from Registrar to MASA.
> PULL was meant to describe the behavior of the pledge to start the
> onboarding while PUSH was more the trigger from the pledge-agent.
> As the enrollment is between the pledge, the registrar, and the CA, I would
> not see a need to include this information in the voucher. This should be
> done as outlined in BRSKI.
> >
> > The MASA, if the pledge supports the desired enrollment protocol,
> > could include the hint.  In fact, the MASA could include an entire URL
> > with meta- data about the protocol to use.
> >
> > This would jive very nicely with the brski-cloud mechanism!!!
> Hm, haven't though about this. In case of standard BRSKI I would not see a
> need, as it would be handled by the domain registrar, but in case of the cloud
> registrar, it would provide the option to point to the right domain registrar
> supporting the enrollment.
I had some further thought on this. I think it would fit to the cloud registrar to the described option 3 in the current draft. If the voucher definition is enhanced with the local RA info, the enrollment options could be provided as well, allowing the pledge to pick the supported one and perform the enrollment. 

If the hint about the protocol support would be included by the MASA to inform the registrar, it may be limited to the  MASA as defined in BRSKI. I'm not sure how this would work with the delegated voucher approach, as the DASA may not know the device capabilities. 
If the voucher definition would be enhanced in case of the cloud registrar, it may also be possible to enhance the voucher request definition, to allow the registrar to populate the information from the domain registrar to the MASA and repeat all options or suitable enrollment options in the voucher (response) provided to the pledge.  

Best regards
Steffen