Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).
Toerless Eckert <tte@cs.fau.de> Tue, 03 May 2022 01:43 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 DA4A4C15E41C for <anima@ietfa.amsl.com>; Mon, 2 May 2022 18:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6THi75BHr9s9 for <anima@ietfa.amsl.com>; Mon, 2 May 2022 18:43:05 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAB9C15E3EA for <anima@ietf.org>; Mon, 2 May 2022 18:43:04 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id F15FD58C4AF; Tue, 3 May 2022 03:42:59 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id E08834EAD9B; Tue, 3 May 2022 03:42:59 +0200 (CEST)
Date: Tue, 03 May 2022 03:42:59 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: anima@ietf.org
Message-ID: <YnCIo9ZhFgmSIXE9@faui48e.informatik.uni-erlangen.de>
References: <YlWUA7xhMU2XtJsz@faui48e.informatik.uni-erlangen.de> <388791.1649870361@dooku> <Ymc57cpieDGAcn1X@faui48e.informatik.uni-erlangen.de> <8866.1651512153@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8866.1651512153@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/hrfIj6mLeUmL-f2-0MmnwUdeh0Q>
Subject: Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.34
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: Tue, 03 May 2022 01:43:06 -0000
On Mon, May 02, 2022 at 01:22:33PM -0400, Michael Richardson wrote: > I am saying that the existing GRASP M_FLOOD specified in RFC8995, > > and I'm saying that we'd have: > $transport-proto /= IPPROTO_UDP ; ... Agreed. > GRASP DULL is easy. > In some sense, for IoT networks, there is *only* the ACP :-) Indeed. But it seems if we want to see constrained BRSKI to get deployed, we need to worry about the most likely deployable/implementable multi-hop discovery of Registrar by Proxies, and i don't think ASM IP Multicast as required for FF05::FD is very likely not it. a) hop-by-hop GRASP as in ACP, just without ACP and over DTLS instead of over TCP/TLS is one option. b) Coap discovery hop-by-hop proxying is probably the other option Either one would need to be defined, likely in a separate document. For a) its easy for me to write it down. For b) i am not even 100% sure how to do it, have to dig. Should be less code ultimately though... > >> We decided that Registrars will be responsible for interoperation, and will > >> support all protocols the operator expects to use. If you buy a Registrar > >> that does not do X and a pledge that only does X, then it fails, and you were > >> stupid. > > > (4) > > > In the first place this needs to be written down. > > > But i'd rather like to argue it away because i think it is an unnecessary > > constraining "hack". > > > Why have all this discovery mechanisms when they are not even used correctly. > > Underspecifying the exact service(s) a Registrar offers is like announcing > > "Oh, go to google for the WHATEVER services". > > No, that's not at all what we said. Registrars need to discoverable anyhow for their IP address. ANd every announcement does include a UDP port number anyhow. And expecting that all stateful registrars operations can always be runniing over the default coap port is contradicting the purpose of discovery and should fail any reasonable INT IESG review IMHO. Besides, i do not believe that all code on all target devices will always share a single coap stack. It would be bad if constrained brski would only work well on those most constrained devices where you MUST use a single coap stack for code-size reasons, but will not work on larger devices where every app easily integrates its own coap stack and therefore has its own sockets for it. > > I don't see that implementations would get more complex, but rather > > simpler if we simply are able to distinguish the different protocol options > > by their service name/parameters and have proxies/clients be able to select > > them. > > I think that we did exactly this. Will only work if registrars can announce which port runs brski with est-coaps and which port runs brski with est-coap-jpy. > > How about cert renewal, did you folks discuss if this would ever be something > > pledges would want to do through the proxy ? In the case of ACP we did > > Nope, never. Just like in BRSKI. How many readers will understand what gaps there are for automatic lifecycle maintenance of the certificate when its not written in the document ? I am not aware that there is a plan for an rfc8994 type document to outsource such text to, and it's IMO easy to fix. IMHO suggested text: Registrars discovered for BRSKI MAY also be used by enrolled devices for certificate/key renewal using the enrolled certificate. Thoughts ? > > IF implementers of a new variant feel that all existing/deployed registrars > > will and should be able to support the new protocol variant (e.g.: brski-xmp-xyz), > > then that protocol option does not need to come up with a new > > variation. > > You can bikeshed the names. I don't really care. Nonono ;-) You (constrained) folks bikeshed' the names by introducing brki-jp and brki-rjp instead of just reusing brki-registrar and brski-proxy from RFC8995. To save 3 or 6 bytes. I only care about distinguishing the names for different protocol versions so i get automatically working registrar and port selection tht will be interoperavble without expecting a superset-of-all-protocols implementation on a registrars. > > What does that mean ? Do all proxies need to support both modes, or > > is there only the requirement for one mode, but some undefined entity has to > > figue out what registrar/proxies in some network should decide to use ? > > What does "what does that mean"? I wrote an explanation, that I don't think you read. See my open questions above. > The "standard" interface from a join proxy to the pledge (if it's DTLS) is to > use CoAP over DTLS, on the port given. The details of how it gets back to > the Registrar is irrelevant to the pledge. Right - miscommunication - i was only worried about the pledge knowing which port a registrar supports statefull and/or stateless. The pledge doesn't see a difference. > (If it's TLS, then it's RFC8995. > (If it's OSCORE/EDHOC, then it's TBD) > >> (Except for CoAP/OSCORE vs CoAPS above) > > OSCORE = ? > OSCORE. RFC8613. Yepp, thanks. found it just a tad in before ;-) I think it would be useful to have a sentence for marketing somehwere in the constrained proxy document saying how this proxy is easily reuseable for any future enrolment protocol variations (for example using the fictional EST-COAP-OSCORE as an example): the whole stateful/stateless operation stays the same, only the service-names for discovery would need to be reinvented. And of course big proxies could run all those protocols in parallel. Cheers Toerless > -- > Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide
- [Anima] Discovery of proxy/registrar insufficient… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Brian E Carpenter
- Re: [Anima] Discovery of proxy/registrar insuffic… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Michael Richardson
- Re: [Anima] Discovery of proxy/registrar insuffic… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Brian E Carpenter
- Re: [Anima] Discovery of proxy/registrar insuffic… Peter van der Stok
- Re: [Anima] Discovery of proxy/registrar insuffic… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Brian E Carpenter
- Re: [Anima] Discovery of proxy/registrar insuffic… Brian E Carpenter
- [Anima] GRASP securty/transport substrate alterna… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Michael Richardson
- Re: [Anima] Discovery of proxy/registrar insuffic… Peter van der Stok
- Re: [Anima] Discovery of proxy/registrar insuffic… Michael Richardson
- Re: [Anima] Discovery of proxy/registrar insuffic… Brian E Carpenter
- Re: [Anima] Discovery of proxy/registrar insuffic… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Brian E Carpenter
- [Anima] FYI: est-coaps registered (was: Re: Disco… Toerless Eckert
- Re: [Anima] Discovery of proxy/registrar insuffic… Michael Richardson
- Re: [Anima] Discovery of proxy/registrar insuffic… Michael Richardson
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Michael Richardson
- Re: [Anima] Discovery of proxy/registrar insuffic… Michael Richardson
- Re: [Anima] Discovery of proxy/registrar insuffic… Michael Richardson
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Carsten Bormann
- Re: [Anima] Discovery of proxy/registrar insuffic… Brian E Carpenter
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Toerless Eckert
- [Anima] Carsten: Re: FYI: est-coaps registered (w… Toerless Eckert
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Michael Richardson
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Toerless Eckert
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Brian E Carpenter
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Michael Richardson
- Re: [Anima] FYI: est-coaps registered (was: Re: D… Esko Dijk