Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)
Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 02 September 2020 04:39 UTC
Return-Path: <brian.e.carpenter@gmail.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 0BA383A0B8D for <anima@ietfa.amsl.com>; Tue, 1 Sep 2020 21:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Level:
X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9d1Xm9QC4Isi for <anima@ietfa.amsl.com>; Tue, 1 Sep 2020 21:39:50 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E05C3A0B87 for <anima@ietf.org>; Tue, 1 Sep 2020 21:39:50 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id b124so2129015pfg.13 for <anima@ietf.org>; Tue, 01 Sep 2020 21:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dWdj66Cl/1BNmQuv1Wx3yLPkAnaqhmpdy3uTw8lOdYk=; b=LXu7+YKnDeJcm+ofBXZ+bIhDXmjAbRL/XVav9QzpVu/pPhIAQqvNBjck/fHHElLJlt dPxicG+DfGYj58BD+NwxWdAEIaBD853ijHQRSrz+15rHmEtxzCnChwJcIIF+7gThZ+60 vQqJbyD00Nbt2DKcomLkhmPqMDvP8NamrsK/5PRQQP0Vtj22B34kx7iZ+7j7e5FThZuD UOA8KhnKN0pXkCIc6UurlSqddVqabqhm9LjKCCcHvrESFD+gdgdKlFG4V1ERpqdRyiBH LZsXQ2W9y0fLiq1KHPh7QEgOYZl0X2N9DflfUbGXe6HmnRzXf2Izgh2nEuWvHLujfBZ8 QbEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dWdj66Cl/1BNmQuv1Wx3yLPkAnaqhmpdy3uTw8lOdYk=; b=Dkdquhtbx9+dKzGJJSaxGGZOtACEChnH6BVdruswKmCclWve2YE56M8sQawTp48MxY +G4UmiTbLV1RFPKsUl7vdotb87lGRHwbq6lhAmSG9HJu7btKm0x8v19ykjIGmdIAVyKA KCnJikIQNBV3CpJYiyCdItuJ2NeWU1GqdcXFe+bjWtoj1inMbOU+qJ2hQWXrXD3AD8G/ qaa8M9ApUKxCV8ibCmkdTNSEDC+Ax5JBAmgzWdHCLSekBvr7lkfyGXPaAWtUUu50T7sM tHPE775zxct+FgO0uZKHrXJEQ2et1JLAOs/PLCwZSZj7ssV8CuycZ7SffFKwNWTy5p6o 5Tqw==
X-Gm-Message-State: AOAM532wwmyyad3KYaQP80ChkEjcVRSkOR5O7UfisDY5owYKx3C22azV hLeJdhn8ObEicXX2gsjI8ul+oZ6gf7/KVA==
X-Google-Smtp-Source: ABdhPJxTCd/AGzvI85fO4kWufLOGxBVSKlr3zgv7PbQu6wql0imWIoz+40Ys3GkuEABsOOWBSedvtw==
X-Received: by 2002:a63:ef47:: with SMTP id c7mr481975pgk.249.1599021589694; Tue, 01 Sep 2020 21:39:49 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id a13sm3617014pfo.49.2020.09.01.21.39.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Sep 2020 21:39:48 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Fries, Steffen" <steffen.fries@siemens.com>, "anima@ietf.org" <anima@ietf.org>
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> <523e10f22ec84f83ad8c0f0b9bc85c4a@siemens.com> <14539.1599016958@localhost>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <7b310617-991a-ce2a-e5e7-1d424ddeab6b@gmail.com>
Date: Wed, 02 Sep 2020 16:39:43 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <14539.1599016958@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/uNRidsN8FuinmFM7N2cQyF8qFds>
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: Wed, 02 Sep 2020 04:39:52 -0000
On 02-Sep-20 15:22, Michael Richardson wrote: > > Fries, Steffen <steffen.fries@siemens.com> wrote: > >> -----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. > > *A* Registrar has to implement the right options. > There could be more than one system with the same CA behind them. > I way prefer to just let the pledge implement one thing. > > Maybe that will cause significant bifurcation in the BRSKI-capable thing > market, but I suspect that most registrars will implement it all. > > >> 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. > > okay. Let me know if you want to try to specify that. At the moment the only defined value for the "AN_join_registrar" objective is the string "EST-TLS", but we could trivially extend it to define another method, or a set of methods. Also the syntax already allows for multiple announcements in one M_FLOOD message, so I'd be surprised if we can't do whatever you want. (I had demo code for announcing a set of methods a long time ago, but I actually simplified it to only announce "EST-TLS" as BRSKI converged.) Brian > > >> 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. > > Yes, okay, I thought that this was in scope for this document. > Or, when I agreed to adopt, I thought that. > > I have quite a few ideas on how to do this: we really ran through them all > during BRSKI/6tisch-zero-touch/SZTP and we settled on a compromise. > > >> 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. > > >> > 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. > > Cool. > I can also see BT and NFC being used for the push. > > >> 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. > > Good. > > >> 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. > > :-) > > -- > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >
- [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